On 07/23/2015 10:35 AM, Peter Chen wrote:
> Assume the interval for each packet is 2ms, the rate is 192 kbytes
> for both FS & HS:
> uac2->p_interval = 2000;
> uac2->p_pktsize = 192 kbytes / 2000 = 96 bytes
>
> And the uac2->p_pktsize is real usb packet length, it means hardware
> would expect there are 96 bytes per 2ms, but the real frame rate is 192k,
> and it needs to 192 * 2 bytes per 2ms in the bus, am I missing
> something?
Hmm? The numerator in that division ('rate') includes the actual frame size:
rate = opts->p_srate * uac2->p_framesize;
uac2->p_pktsize = rate / uac2->p_interval;
Which means for 192KHz, stereo 16bit, rate is 768000. In this case,
bInterval = 4 doesn't work, as the packets would become >512 bytes, so
the bandwidth wouldn't suffice.
> Another think I am not understand is why playback uses IN endpoint?
> Don't this playback mean the data is from host, and play at device side?
That's a little confusing on first sight, but actually quite logical:
The ALSA capture stream is the one that allows applications on the
gadget to record audio, which is data that is sent *from* the host
(playback on their side) to the device, using OUT tokens.
The ALSA playback stream is the one that allows applications on the
gadget to playback audio, which is data that is sent *to* the host
(capture on their side) by the device, using IN tokens.
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html