Re: [PATCH 0/4] usb: gadget: f_uac2: cleanups and capture timing

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

 



On Mon, Aug 25, 2014 at 3:07 PM, Daniel Mack <daniel@xxxxxxxxxx> wrote:
> On 08/25/2014 11:30 AM, Jassi Brar wrote:
>> On Mon, Aug 25, 2014 at 2:57 PM, Daniel Mack <daniel@xxxxxxxxxx> wrote:
>>> On 08/25/2014 11:23 AM, Jassi Brar wrote:
>>>> On Mon, Aug 25, 2014 at 2:14 PM, Daniel Mack <daniel@xxxxxxxxxx> wrote:
>>>
>>>>> The easiest is probably really to just calculate correct packet sizes
>>>>> and stick to them. After all, the actual clock is really arbitrary, we
>>>>> just have to pick something that is in the range of the sample rate.
>>>>>
>>>>> I'll cook up an alternative patch and do some tests with Sebastian off-list.
>>>>>
>>>> How about configuring bInterval and wMaxPacketSize to get the desired rate?
>>>>
>>>> For ex, 48KHz/2/S16, we need 192bytes/millisec. So we set bInterval=1
>>>> (or 4 for HS) and wMaxPacketSize=192 for that configuration.  For
>>>> 44.1KHz/2/S16 we need 176.4bytes/millisec, so we set
>>>> wMaxPacketSize=178 and send packets of length in {176, 176, 176,
>>>> 176,178} pattern.
>>>
>>> Yes, something like that. But you can't modify wMaxPacketSize in
>>> accordance to the sample rate and format, but just send short packets.
>>>
>> We can't change rate once the f_uac2 module is loaded. So
>> wMaxPacketSize changes only across module loads.
>
> Yes, but we shouldn't rely on wMaxPacketSize but really just send
> packets of the right size. This is what other USB audio devices do as well.
>
Yup, that should do too.  Setting wMaxPacketSize to just enough length
seemed more optimized and robust to me. But I have not strong feelings
here.

> And btw - we could also change the logic of f_uac2 so the sample rate
> can be changed at runtime. The only constaint is that the counterpart
> device on the gadget side must not be active when this happens. Whatever
> part of the system comes up first (USB or ALSA) defines the sample rate
> and the format. But I'll save that for later :)
>
Properly supporting multiple sampling rates required a topology more
complicated than now, so I skipped it. IIRC some 'clock selector' unit
needs to be added to have a UAC2 compliant method to change rates from
Host side.

Thanks
Jassi
--
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