Hi Daniel!
Hi Jonathan,
On Aug 7, 2007, at 12:49 AM, Jonathan Leonard wrote:
I can get clear playback of a wav file through aplay and XMMS
with the soundcard assigned as card 0, or hw:0 However accessing
the headphone output on the kore controller has not been possible
for me yet.
The headphone output on the Kore controller is a separate channel
which you should be able to access as "hw:0,0,1".
Excellent - I'll try that!
Concerning Jack, I have only been able to connect to jackd using
a buffer size of 1024. I have tried three sample rates: 44.1, 48
and 96k; these are fine but only with 1024 frames or greater.
Depending on various other settings I may set in qjackcontrol, the
cpu usage of jackd varies widely. For example, if I select
anything other than 2 ins and outs, its either 90% cpu, or the
server will not connect. With the Kore Controller, if I select
what should be the proper number of channels; 2 ins and 6 outs, no
connection. After some time experimenting like this,
occassionally qjackcontrol will blink out of existence entirely,
which I confirm with a ps -A in the terminal. Or, the entire OS
freezes without override and a system restart is required. Also
when jack is connected at 1024 frames, there are about 10 xruns
per second.
I'm not sure whether your jackd problems are acutally related to
the driver at all.
Have you tried your jackd config with any other driver, maybe some
onboard soundcard in your computer? Probably someone with more
jackd experience can give some more substantiated information :)
Yes I have tried the same config with another soundcard. The
Echoaudio Layla20 which has worked reliably with a range of settings.
+++/alsa-kernel/usb/caiaq.c
Ln 63:
.periods_bytes_min = 4096
Is this limit cool for low latency? Is it possible to get lower
buffer sizes than 1024 frames?
My primary jack problem, and with aplay is I cannot use the NI
devices at a period size less than 1024 frames.
Using aplay I cannot get beneath buffer size = 683 without this error:
aplay: set_params:969: Can't use period equal to buffer size (683 ==
683)
This is somewhat echoed by calling the sw_params while a stream is
playing:
$cat /proc/asound/card0/pcm??/sub?/sw_params
I found another alsa patch that was submitted to provide lower
latency response here.
But of course that is a different device.
I also found a response from alsa-dev from clemens asking why that
limit is there at all.
Given, we don't know jack. (har har har) But could I solve my issue
by changing this minimum in the c file and rebuilding? Or is this a
limit set from 'on high'? Hoping for a technical explanation...
Thanks for your help and the driver!!!
jonathan adams leonard
ps: looking forward to those matrix notes being updated and cleaned
up though I hope the migration to wiki doesn't slow this down.
Personally I know there is newer info to add for RME support because
my multiface II works with JAD live DVD and there is no mention of
this in the matrix - only the pci cards.-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
