usb audio endpoint single buffer possible?

sgpiqx · ‎2016-06-09

Posted on June 10, 2016 at 05:54

Anyone tried before USB audio playback with endpoint single buffer only? or must double buffer?

reason is I use STM32F072 and it's USB buffer only 1K. My device will have playback and recording at 48KHz 24bits. So if must be double buffer I will exceed 1K limitation.

#usb #audio #audio #audio #usb #device #usb

slimen · ‎2016-06-10

Posted on June 10, 2016 at 11:16

Hi piqx.sg,

I suggest you have a look at this

http://www.st.com/content/ccc/resource/technical/document/user_manual/01/c6/32/df/79/ad/48/32/CD00158241.pdf/files/CD00158241.pdf/jcr:content/translations/en.CD00158241.pdf

manual: STM32 USB-FS-Device development kit, in section 9.4 and this

http://www.st.com/content/ccc/resource/technical/document/user_manual/99/6b/a7/ec/2a/4b/4b/47/DM00104543.pdf/files/DM00104543.pdf/jcr:content/translations/en.DM00104543.pdf

: STM32F0x2xx USB Full Speed Device Library.

Regards

tsuneo · ‎2016-06-12

Posted on June 12, 2016 at 16:58

> usb audio endpoint single buffer possible?

Generally speaking, it's ''possible'', but your device could occasionally drop a frame of data stream. If you would like guarantee no data drop, double buffer should be required (in the cost of one frame delay).

Usually, data drop wouldn't occur even with single buffer, while all of data streams are steadily running on a PC USB line. In this situation, the completion timing of your isoc endpoint occurs almost at the same phase in a frame (with some fluctuation cased by bit stuffing). It's because PC host controller and OS schedule isoc transactions in such way (isoc transaction starts immediately after SOF. the order of isoc transactions are fixed, if two or more isoc endpoints are registered). And then, your firmware has almost one frame interval from a completion of the isoc transaction to the next start of the transaction.

However, just when other isoc endpoint (of other device) starts/stops on the same bus, the timing of your isoc transaction could move in the frame drastically. If the timing of your isoc endpoint would move forward too much, your firmware couldn't finish endpoint unload/priming until this new timing. And then, data drop could occurs at the frame.

Of course, this ''accident'' doesn't occur so often. You may take this risk to keep the design in low cost.

As of the ''Device'' (not OTG) USB engine of STM32,

the datasheet assumes double-buffer for isoc endpoints. No description of isoc single-buffer. I haven't tried single-buffer configuration yet. But I remember, the same USB RAM location to the both of double buffers could work.

Tsuneo

sgpiqx · ‎2016-06-12

Posted on June 13, 2016 at 07:27

Hi forumSTM32

thank you for pointing to those app notes, I have read them before.

My issue is exploring possibility having 96khz 24bit playback with STM32F0 series which if using double buffering is kinda impossible given 1K limitation of USB packet memory.

Hi Tsuneo,

Thank you very much for your explanation.

''But I remember, the same USB RAM location to the both of double buffers could work.''

I tried this double buffer same USB packet memory location, it works!

If only set as single buffer I have confirmed it will not work, will lose 1 frame.

About endpoint : ''the order of isoc transactions are fixed''

Are they always fixed? regardless stop and start of any isoc endpoints?

The idea is if they always fixed I could copy the playback endpoint buffer during recording endpoint buffer is filled and vice versa. I just need to make sure I finish copying within time for transfering isoc data. Furthermore I assume the timing won't move too much as I use almost all of Full speed bandwidth with 96khz/24bits playback and 48khz/24bits recording (about 880 bytes+128 bytes for control = 1008 bytes per frame)

Something like this

[SOF][Isoc playback][Isoc recording][Ctrl][SOF][Isoc playback][Isoc recording][Ctrl]

[copy Isoc play] [copy Isoc rec] [copy Isoc play] [copy Isoc rec]

What do you think, workable?

Of course if they are not fixed, and can be in any order due to start and stop, well I kinda screw up if still insist using stm32f0 series (or to be precise almost all stm32 except those high end and expensive chip that can support high speed).

Thanks again and btw tsuneo just wonder if you have personal blog/website that I can follow?

SG