Re: Audio I/O parameters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 24, 2013 at 2:42 AM, James Stone <jamesmstone@xxxxxxxxx> wrote:
> On Wed, Jul 24, 2013 at 12:23 AM, James Stone <jamesmstone@xxxxxxxxx> wrote:
>> On Tue, Jul 23, 2013 at 11:50 PM, Torstein Hegge <hegge@xxxxxxxxxxx> wrote:
>>> On Tue, Jul 23, 2013 at 21:13:23 +0100, James Stone wrote:
>>>> On Fri, Jul 19, 2013 at 4:17 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>>>> > On Fri, 19 Jul 2013, James Stone wrote:
>>>> >
>>>> >> > The questions now are:
>>>> >> >
>>>> >> >         Why are the same requests sent over and over again?
>>>> >> >
>>>> >> >         Why does the ALSA driver attempt to set the clock frequency
>>>> >> >         while the clock is actively in use?
>>>> >> >
>>>> >> >         Has this behavior changed since the 3.5 kernel?
>>>> >> >
>>>> >>
>>>> >> Well, I think these requests may correspond to the lights flashing on
>>>> >> and off on the front of the device. When starting the device in 3.5 at
>>>> >> 256 frames/period (duplex), the lights flash on and off 2 times, in
>>>> >> the current patched 3.8 version I have been using, the device lights
>>>> >> flash on and off 4 times before starting jack with exactly the same
>>>> >> settings - so it seems for some reason, the requests are going through
>>>> >> multiple times on the 3.8 kernel but not on 3.5. I will send a 3.5
>>>> >> usbmon trace of a successful start off list (plus the same for 3.8?)
>>>> >> if it would be useful.
>>>> >
>>>> > I don't know -- it's up to Clemens.
>>>> >
>>>> > Alan Stern
>>>> >
>>>>
>>>> Hi Alan,
>>>>
>>>> Just tried a few old kernels, and it seems that the bug I am
>>>> experiencing was introduced at the start of 3.7 - kernel 3.6.11 is
>>>> fine, and all the 3.7 series kernels are broken. So it seems it is not
>>>> the updated ehci usb code that is directly responsible for the
>>>> realtime audio problem. I have been trying the kernels from:
>>>> http://kernel.ubuntu.com/~kernel-ppa/mainline/. Any suggestions on how
>>>> to further zoom in on the culprit commit?
>>>
>>> Can you reproduce the problem on a 3.10 kernel? I suspect this is
>>> related to the commit 61a70950 "ALSA: usb-audio: Move configuration to
>>> prepare" in kernel 3.7, which introduced calls to set sample
>>> rate in prepare, even if the sample rate is unchanged. It looks like
>>> jackd calls prepare twice when starting, which is consistent with two
>>> get rate/set rate sequences.
>>>
>>> The unnecessary set rate shouldn't happen with kernel 3.10, as it
>>> includes fa92dd77 "ALSA: usb - Avoid unnecessary sample rate changes on
>>> USB 2.0 clock sources", which says in the commit message: "The Scarlett
>>> 2i2 seems to take almost 500 ms to set the sample rate, even if the
>>> clock is currently set to that value. This patch speeds up prepare of
>>> the device, by avoiding setting the clock to something it already is."
>>>
>>>
>>> Torstein
>>
>> Thanks for this info. I just tried it out, and the device starts up
>> much more cleanly - no flashing lights etc. at longer latencies. It
>> will still not start jackd at 256 frames/period, but this might need
>> Clemen's do not trust too-big wMaxPacketSize values patch added.. Will
>> report back.
>>
>> James
>
>
> Ok - this does seem to be a vast improvement over 3.8.x (and even, in
> some ways the 3.6x series) - with the addition of Clemen's patch.
> However, very low realtime latencies (which seemed to be somewhat
> possible - 64 frames/period or lower - in the 3.6x series) will no
> longer work properly. 128 frames/period looks fairly usable. Will
> continue with bisect to see if I can discover anything else.

Ok -from the bisect, the problem of not being able to get to sub
64-frames per period starts with:

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=fc600432cd23e35c85de2ff4468d816d6938a112

Could this be the offending deletion?

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/sound/usb/endpoint.c?id=fc600432cd23e35c85de2ff4468d816d6938a112

??

James
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux