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.
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 :)
Daniel
--
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
