[Jack-Devel] jack vs. motu (usb)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Jack-Devel] jack vs. motu (usb)

Fernando Lopez-Lezcano
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

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: jack vs. motu (usb)

Fons Adriaensen-3
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)

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: jack vs. motu (usb)

Fernando Lopez-Lezcano
On 10/25/2016 01:28 PM, Fons Adriaensen wrote:
> 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 ?

Just using aplay alone... it plays "fine" except that it takes a few
seconds for sound to actually appear in the outputs.

>> 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.

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...

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: jack vs. motu (usb)

Fons Adriaensen-3
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)

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: jack vs. motu (usb)

Fernando Lopez-Lezcano
On 10/25/2016 02:58 PM, Fons Adriaensen wrote:

> 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 ?

"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

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: jack vs. motu (usb)

Fons Adriaensen-3
On Wed, Oct 26, 2016 at 12:48:29PM -0700, Fernando Lopez-Lezcano wrote:

> >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.

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)

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: jack vs. motu (usb)

Fernando Lopez-Lezcano
On 10/26/2016 01:32 PM, Fons Adriaensen wrote:

> On Wed, Oct 26, 2016 at 12:48:29PM -0700, Fernando Lopez-Lezcano wrote:
>
>>> 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.
>
> 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

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Loading...