Raspberry PI 2B/3 and USB audio

Herbert J. Skuhra herbert at gojira.at
Mon Nov 12 19:46:17 UTC 2018


On Sun, 11 Nov 2018 13:52:14 +0100, Hans Petter Selasky wrote:
> 
> On 11/10/18 12:24 PM, Herbert J. Skuhra wrote:
> > Hi,
> > 
> > if you use an USB sound card on your Raspberry PI 2B/3, can you please
> > answer the following questions:
> > 
> > - which USB sound card?
> > - do you have bad audio on current or stable/12 after r339388?
> > 
> > My "Creative Technology Ltd Sound Blaster Play 2" device sounds very
> > bad. Meanwhile more changes were commited but they don't fix audio
> > completly.
> > 
> 
> Hi,
> 
> Some background:
> 
> The USB controller in Raspberry PI is running HIGH-speed USB. Many USB
> audio device are FULL-speed USB. In order for a FULL-speed USB device
> to work in a HIGH-speed USB environment all data transfers need to go
> through a so-called transaction translator. This transaction
> translator operate on chunks of data, 171 bytes maximum. That means if
> a USB audio stream generates 1000 packets per second, then suddenly a
> bunch of smaller packets will be needed. This puts some stress on the
> DWC OTG driver and there might be some room for improvement in this
> area too, but the basic sympthom is that the DWC OTG driver in FreeBSD
> is not always able to keep up with the timing required for these
> so-called split transactions. One idea is to move all DWC OTG IRQ
> handling away from CPU-0. I'm not sure if cpuset supports this yet on
> armv7 // arm64. Might have to be done in the driver.
> 
> Further some audio device use non-adaptive clocks, which means the
> recording channel must be active along with the playback channel else
> jitter will occur.
> 
> The recommendation for RPI is a HIGH-speed USB audio device (should be
> clearly marked in the specification). Using a HIGH-speed USB audio
> device will reduce the number of interrupts significantly.

Well, the sound card worked perfectly fine so far... both on FreeBSD
and Arch Linux ARM... no luck with NetBSD. Never mind! I am obviously
the only user affected by this "fix" (r339388).

--
Herbert


More information about the freebsd-arm mailing list