Rpi3: USB-Audio: no fault indication when faulting

[hase-berlin]

Context:

Rpi3, Power: Lab bench power supply feeding 5.3V to header pins, ethernet+wifi enabled.
processor temperature: Seek Thermal flir estimates 46°C, index finger not burned => within limits.
approximate load average: 0.18, 0.48, 0.58

pi@audio-transmit-pi:~ $ uname -a
Linux audio-transmit-pi 4.4.7-v7+ #877 SMP Sun Apr 17 12:48:36 BST 2016 armv7l GNU/Linux

pi@audio-transmit-pi:~ $ lsusb
Bus 001 Device 004: ID 08bb:2902 Texas Instruments PCM2902 Audio Codec
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

steps to reproduce:
/usr/bin/gst-launch-1.0 -v alsasrc device=plughw:CODEC ! "audio/x-raw,rate=48000,channels=2" ! audioconvert ! alsasink
and wait a while.

variants tried:

• play to onboard audio (as shown)
• play to USB-Audio (same device as recording)
• vary the rate= between 8k and 48k
• run the gst-launch in an strace-f

observations:

• when started, the audio plays as expected
• after a while, clipping/gap noises appear
  -- but the audio recovers from that
• a little later, audio stops altogether
  -- never recovers
• the playthrough never recovers.

When run in strace, the patter scrolling across the screen, does not change when the audio stops.
The lower the sample rate, the longer the time between "works" and "nope, not any longer" seems to be (but my measurements are to few to give a statistically relevant sample).

my conclusions: I am missing something of the USB-audio thingy does not work (not mutually exclusive, it appears).

Perusing the issue tracker I came across #197 and that seemed to explain a lot.
But that issue was fixed long ago.

additional notes:
such a playthrough is obviously silly, but it is only part of what I am working on, obviously. I just use this simplified example to exclude as much environment as possible.
Goal is to record from the input device and stream the audio over WiFi (reliable Multicast, tbd.)

What really puzzles me is the fact, that when the audio fizzles out and when it stops working entirely, the gstreamer process gets no indication whatsoever. The device(s) seems to function normally.
I also do not see anything in the logs; with an earlier firmware I saw messages about possibly lost data; these are gone after rpi-update.

I am new to debugging driver issues on the RasPi, so whichever friendly person takes a shot at this will have to guide me; I am not new to debugging in general (neither hardware not software).

Please tell me what to measure so we can get to the bottom of this. Or at least deep enough for a fix.

merci
hase

[hase-berlin]

Tried the same on RPi.
Result: the same problem, but experienced much faster.
Also the influence of the data rate from the USB interface (and therefore the samplerate) is confirmed: the single-core Pi can not handle 44k1/16/2 for even e few seconds. At 16k/16bit/2chan the problem still can be reproduced but takes longer.

To me this seems like the usb driver loosing sync when packets are dropped, as hinted by #197.

There also seems to be an dependence on my method of reading the audio from the USB interface.
Using ices2 with ALSA-input and an icecast2 server running on the Pi3, the audio plays fine for hours.
Reading with gstreamer the problem can be reproduced every time.

[popcornmix]

Have you tried with dwc_otg.fiq_fsm_mask=0xF added to cmdline.txt?
That improved USB bandwidth in some circumstances (and is now a default option in rpi-update kernel).

[hase-berlin]

I solved my acute problem by changing the sound concept for the ongoing project (an art installation) fundamentally. This removes my pressure for time on this.

If you just want to close this - no problem with me.
But if you are curious like me and want to get to the bottom of the issue: I'll do whatever you tell me to.
And btw: thanks for hopping on, much apprechiated!

--Test again.
(conditions changed slightly, power is now Samsung USB power supply)
file cmdline.txt:
dwc_otg.fiq_fsm_mask=0xF dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
Kernel:
pi@audio-transmit-pi:~ $ uname -a
Linux audio-transmit-pi 4.4.7-v7+ #877 SMP Sun Apr 17 12:48:36 BST 2016 armv7l GNU/Linux
pi@audio-transmit-pi:~ $ cat /proc/cmdline
8250.nr_uarts=1 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa02082 bcm2709.serial=0x18e57e86 smsc95xx.macaddr=B8:27:EB:E5:7E:86 bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 dwc_otg.fiq_fsm_mask=0xF dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Result: no change.
Audio starts fizzle after some time (current attempt: ca. 2 minutes). The "fizzle" is a sound a little like hard clipping.
Audio then comes back (without the fizzle) and stops shortly after (ca. 90s).
Reproduced 3 times.

The gst-launch process does not see either event (fizzle and off) as error.

test again with different USB sound device.
Swapped the TI for noname (dmesg: New USB device found, idVendor=0d8c, idProduct=013c)
Seems stable for much longer: 4 minutes and counting.

changing test specifications: create some interrupt load: (sudo ls -lR / in an ssh session oder wired ether)
Result: sounds a little like gaps in the audio. Gaps vanish when the ls finishes. (anther ls run only reads the cache --> not the same at all other approach sudo find /var/log -exec od -h {} ;).

Still stable regarding fizzle-out.
Also still the same crappy sound quality as usual and expected :-)

Btw:

• reading the Burr-Brown with gstreamer1.0 reproduces the problem
• reading the Burr-Brown with ices2/ALSA (and streaming to a pi-local icecast2 an over network to another computer) does not show the problem
• reproduced with Behringer Xenyx Q502USB; this mixer has the same TI/Burr-Brown codec as the U-control UCA202

[P33M]

For posterity, this was likely fixed recently as there was a bug with 44.1kHz USB playback. Noname devices typically only support 48kHz rates which don't exhibit the issue.