[alsa-devel] Missing exactly 3 of 8 audio packets?

[Daniel Mack]

Hi Daniel,

Thanks for the detailed report.

On 21.11.2012 21:13, Daniel Griscom wrote:
> On to the next problem we're having with our USB audio card. Recap: 
> simple USB Audio Class embedded stereo audio card, running at 44.1kHz 
> or 48kHz, using the 3.6.6 kernel and its associated ALSA modules to 
> drive it, running on Jetway ND9D-2700, with an Atom D2700 and NM10 
> chipset. Output of "sudo lsusb -v" for card is appended below.
> 
> Problem: we're experiencing strange hiccups in the delivery of audio 
> from the motherboard to the card. At 48kHz, the motherboard should 
> send a 6-frame packet to the card once per high-speed microframe 
> (every 125us). This usually works, but sometimes there are two 
> closely related failures:
> 
> 1) Once in a while (every few seconds or minutes) a single packet 
> will be missed
> 
> 2) Once in a longer while (every few minutes or hours), the system 
> will go into a continuing error condition where three of every eight 
> packets are missed.
> 
> In both cases, "missed" means that ALSA consumes the output audio 
> from my motherboard application, but never sends a packet to the 
> audio card. No USB errors, no logged messages; it just disappears.
> 
> 
> The second case has one very interesting symptom. The pattern of 
> missed frames is amazingly rigid, and repeats the following pattern 
> endlessly (each character is a 125us slot for a packet, "F" is a 
> transmitted packet, "-" is a missing packet):
> 
> FFFF--F-
> 
> So, with eight microframes per millisecond where packets can be sent, 
> the fifth, sixth and eighth packets are missed, and this repeats for 
> at least a number of seconds. Very, very strange.
> 
> Using a Beagle 1200 I can see that there are no USB errors: the 
> packet is just not sent. Audio continues unabated in the other 
> direction. Timing always looks good, no other traffic on that USB 
> port.
> 
> 
> We've been chewing on this issue for a while. To me, it sounds like 
> this could only happen in the ALSA code where the stream of audio is 
> broken into individual USB packets. Unfortunately, I'm having a heck 
> of a time navigating the ALSA source code, and frankly have gotten no 
> traction at all.

I guess the only reason for what you see is that
snd_usb_endpoint_next_packet_size() returns an unusual value every time
a packet is missing, and question is why.

That function's operation is based on two values: the current momentary
frequency as reported by the sync endpoint (ep->freqm), and the phase
accumulator which carries the lower 16bits of the previous calculation,
which is preserved for precision sustainment.

> Any thoughts on what this might be, or on what further tests we might do?

Please try to catch the input and output parameters of that function
when USB packets are missed and also have a closer look at the sync
packets that are sent to the host shortly before that happens. Is there
any pattern in that?


Daniel