25 Oct
2016
25 Oct
'16
2:49 p.m.
Hi all!,
Has anyone seen this and hopefully found a workaround?
To make a long story short, it takes a Motu card of the new generation
(24ao, 1248, etc) about 6 seconds to change the sampling rate (!). That
happens when switching from one sampling rate to another, and also after
first connecting the card to a Linux system over USB (Fedora 23).
When Jack is started for the first time after changing sampling rate, or
right after the card is plugged into the system, it probably asks the
ALSA driver "can this card do this sampling rate with these other
parameters?" and the answer is "yes", but when actually setting it it
apparently fails and jack does not start.
Now, if after that you slowly count to 7 (just to be safe) and try to
start Jack again, it just works (I presume the card has already finished
switching sampling rates in the background while you wait, and
everything is fine).
When using aplay to help debug this it turns out that aplay does not
complain, and it happily plays the soundfile, but nothing comes out of
the speakers for the first few seconds - I presume until the card
switches sampling rate.
Once the sampling rate has been defined at least _once_ then Jack has no
problem to start (over and over again) and aplay plays files with sound
from the beginning.
If you access the status and configuration web server in the Motu you
can switch the sampling rate and you see the clock lock icon turn
blinking red and then solid white once the change is done. Also,
alsamixer and amixer show a single read only "control" that is actually
the lock status indicator (the lsusb descriptors also show another r/w
control that can be used to _set_ the frequency but that is somehow not
reflected in the alsamixer/amixer interface).
Suggestions? Patches? :-)
-- Fernando
25 Oct
25 Oct
3:28 p.m.
On Tue, Oct 25, 2016 at 12:49:44PM -0700, Fernando Lopez-Lezcano wrote:
When using aplay to help debug this it turns out that
aplay does not
complain, and it happily plays the soundfile, but nothing comes out
of the speakers for the first few seconds - I presume until the card
switches sampling rate.
Is that sampling rate actually set by aplay, or before by using HW
controls ?
Once the sampling rate has been defined at least
_once_ then Jack
has no problem to start (over and over again) and aplay plays files
with sound from the beginning.
If you access the status and configuration web server in the Motu
you can switch the sampling rate and you see the clock lock icon
turn blinking red and then solid white once the change is done.
Also, alsamixer and amixer show a single read only "control" that is
actually the lock status indicator (the lsusb descriptors also show
another r/w control that can be used to _set_ the frequency but that
is somehow not reflected in the alsamixer/amixer interface).
A few lines of python could probably set the sample rate using the
web interface, wait until the card is ready, then start Jack.
Or find out what's required on the usb endpoint that sets the
sample rate.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
4:30 p.m.
On 10/25/2016 01:28 PM, Fons Adriaensen wrote:
Or just have a script that tries to start jack, fails, waits a bit and
tries again (replacing jackd - a nasty hack).
It would be best to not depend on the web interface as that might not be
always available when we connect through usb.
I have not looked at the jack source to try to figure out why it is not
working while aplay does - maybe the card no longer generates
interrupts? Also, if the clock somehow changes while jack is running
(for example I disconnect the clock source if slaving to external
clock), jack goes into la-la land and we need to quit everything and
restart it to get things going again. Too bad...[*]
-- Fernando
[*] eventually I want to get these cards working with AVB...
On Tue, Oct 25, 2016 at 12:49:44PM -0700, Fernando
Lopez-Lezcano wrote:
Just using aplay alone... it plays "fine" except that it takes a few
seconds for sound to actually appear in the outputs.
When using aplay to help debug this it turns out
that aplay does not
complain, and it happily plays the soundfile, but nothing comes out
of the speakers for the first few seconds - I presume until the card
switches sampling rate.
Is that sampling rate actually set by aplay, or before by using HW
controls ? Once the
sampling rate has been defined at least _once_ then Jack
has no problem to start (over and over again) and aplay plays files
with sound from the beginning.
If you access the status and configuration web server in the Motu
you can switch the sampling rate and you see the clock lock icon
turn blinking red and then solid white once the change is done.
Also, alsamixer and amixer show a single read only "control" that is
actually the lock status indicator (the lsusb descriptors also show
another r/w control that can be used to _set_ the frequency but that
is somehow not reflected in the alsamixer/amixer interface).
A few lines of python could probably set the sample rate using the
web interface, wait until the card is ready, then start Jack.
Or find out what's required on the usb endpoint that sets the
sample rate.
4:58 p.m.
On Tue, Oct 25, 2016 at 02:30:16PM -0700, Fernando Lopez-Lezcano wrote:
I have not looked at the jack source to try to figure
out why it is
not working while aplay does - maybe the card no longer generates
interrupts? Also, if the clock somehow changes while jack is running
(for example I disconnect the clock source if slaving to external
clock), jack goes into la-la land and we need to quit everything and
restart it to get things going again. Too bad...[*]
What happens with the test app that comes with the alsa-pcmi lib ?
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
26 Oct
26 Oct
2:48 p.m.
On 10/25/2016 02:58 PM, Fons Adriaensen wrote:
On Tue, Oct 25, 2016 at 02:30:16PM -0700, Fernando
Lopez-Lezcano wrote:
"can't set playback hardware parameters" (or capture sometimes). This is
trying out alsa_delay with debugging enabled through the environmental
variable and changing the sampling rate from the last one used
(./alsa_delay hw:2 hw:2 48000 128 2). It says the same thing when
retrying until it just works again.
-- Fernando
I have not looked at the jack source to try to
figure out why it is
not working while aplay does - maybe the card no longer generates
interrupts? Also, if the clock somehow changes while jack is running
(for example I disconnect the clock source if slaving to external
clock), jack goes into la-la land and we need to quit everything and
restart it to get things going again. Too bad...[*]
What happens with the test app that comes with the alsa-pcmi lib ?
3:32 p.m.
On Wed, Oct 26, 2016 at 12:48:29PM -0700, Fernando Lopez-Lezcano wrote:
So having a loop, retrying a few times while printing a message
to the user plus some sleeping, should solve this.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
What happens
with the test app that comes with the alsa-pcmi lib ?
"can't set playback hardware parameters" (or capture sometimes).
This is trying out alsa_delay with debugging enabled through the
environmental variable and changing the sampling rate from the last
one used (./alsa_delay hw:2 hw:2 48000 128 2). It says the same
thing when retrying until it just works again.
27 Oct
27 Oct
12:35 p.m.
On 10/26/2016 01:32 PM, Fons Adriaensen wrote:
On Wed, Oct 26, 2016 at 12:48:29PM -0700, Fernando
Lopez-Lezcano wrote:
So having a loop, retrying a few times while printing a message
to the user plus some sleeping, should solve this.
Yes, that is possible of course but is not a real solution as I see it,
at least not something that is general purpose and I can deploy. I have
to try to find our exactly how it is failing, for example printing the
alsa hw/sw parameter space when it fails and when it succeeds (after all
aplay manages to "play" in the same conditions).
-- Fernando
What
happens with the test app that comes with the alsa-pcmi lib ?
"can't set playback hardware parameters" (or capture sometimes).
This is trying out alsa_delay with debugging enabled through the
environmental variable and changing the sampling rate from the last
one used (./alsa_delay hw:2 hw:2 48000 128 2). It says the same
thing when retrying until it just works again.
2977
days inactive
2979
days old
jackaudio@lists.linuxaudio.org
6 comments
2 participants
participants (2)
-
Fernando Lopez-Lezcano -
Fons Adriaensen