Stuttering audio using USB Creative SoundBlaster MP3+

[bboffey]

Hi Mike,

So.. first up I've 'solved' the issue which is stuttering audio with shairport-sync using a USB Creative SoundBlaster MP3+ with Pi MusicBox which didn't work out of the box as it were. I'm hoping that with your expertise we can see whether this is a bug in shairport-sync or elsewhere before I suggest a change to Pi MusicBox. Or if this is a wonderful quirk of dodgy old hardware :)

I'm running MusicBox 0.6 (http://www.pimusicbox.com) which includes

• shairport-sync: 2.1.15-openssl-Avahi-ALSA
• Linux MusicBox 3.18.7+ (development) normalize whitespaces in scripts/shairport-sync.conf #755 PREEMPT Thu Feb 12 17:14:31 GMT 2015 armv6l GNU/Linux
  This is running on a rev 1 Raspberry Pi Model B

By default /etc/asound.conf is

pcm.!default {
    type hw
    card 1
}
ctl.!default {
    type hw
    card 1
}

My USB sound card (an old Creative Soudblaster MP3+ running via an external powered hub due to it's 500mA power requirement) works fine for playing audio through mopidy with this default, but stutters terribly and sometimes doesn't even play at all with shairport-sync.

Looking at the default settings used I can see this

cat /proc/asound/card1/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 6000
buffer_size: 18000

This would (if my new found understanding of ALSA is correct) give us an interrupt every 6000_4 = 24000 bytes or (24000/192000 = 0.125) every 125ms and a buffer of 18000_4 = 72000 Bytes or 72kB.

There are no errors from in shairport itself (from running with -vvv --statistics) so I assumed something in ALSA land, perhaps related to funkiness of timing, latency and the USB on the Pi or with DMA and USB Audio devices, so set about tweaking period_sizes and buffer_sizes.

• 6000/18000 - stutters like hell ( interrupt every 125ms, 72kB buffer)
• 480/9600 - smooth (10ms, ~39kB)
• 4800/9600 - stutters like hell (100ms, ~39kB)
• 960/9600 - smooth (20ms, ~39kB)
• 1920/9600 - smooth (50ms, ~39kB)
• 1920/19200 - smooth (every 50ms, ~77kB)
• 4800/19200 - stutters a bit (100ms, ~77kB)
• 7200/19200 - no audio (150ms, ~77kB)

ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred
Error -32 in delay(): Broken pipe. Delay reported is 0 frames.
Error getting dac_delay at start of loop.

• 7200/28800 - no audio (150ms, ~115kB)

ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred
Error -32 in delay(): Broken pipe. Delay reported is 0 frames.
Error getting dac_delay at start of loop.

• 1920/28800 - smooth (50ms, ~115kB)

RTP: Packets out of sequence: expected: 31006, got 31007.
requesting resend on 1 packets starting at 31006.
RTP: Packets out of sequence: expected: 31010, got 31006.
RTP: Packets out of sequence: expected: 31007, got 31010.

There were sync errors reported for most of the settings but rarely or no missing or late packets and no audible hiccups so I've not included these.

It looks as if having too large a buffer causes out of sequence problems and too large a latency causes stuttering. Which I guess makes sense! I settled on this setup which seems to work fine

pcm.!default {
    type plug
    slave.pcm {
        type dmix
        ipc_key 1024
        slave {
            pcm "hw:1"
            rate 48000 
            period_time 0
            period_size 1920
            buffer_size 19200
        }
    }
}
ctl.!default {
    type hw
    card 1
}

Any thoughts on why this stuttering only occurs when using shairport-sync and not mopidy/aplay with the default settings? Have I missed anything here?

Thanks.

[mikebrady]

Thanks for this interesting post. I'm not an expert on this stuff at all, but it looks to me that your default device is sending audio to the real card at hw:1 at 48,000 samples per second. Shairport Sync outputs at 44,100 samples per second, so something in the alsa subsystem must be translating from 48,000 to 44,100. A question I have is whether the real device – presumably the SoundBlaster MP3+ – at hw:1 is capable of 44,100 sample per second operation?

[bboffey]

Ah yes, sorry I missed that bit of info.

The card has an analogue and digital mode and both input and output. I believe from some reading online and interrogation of the card that it's capable of 48khz playback in analog mode and 44.1khz or 48khz in digital and for capture.

Looking at the output of cat /proc/asound/card1/stream0 I get the following

Creative Labs Sound Blaster MP3+ at usb-bcm2708_usb-1.3.4, full speed : USB Audio

Playback:
  Status: Stop
  Interface 1
    Altset 1
    Format: S16_LE
    Channels: 2
    Endpoint: 1 OUT (ADAPTIVE)
    Rates: 48000

Capture:
  Status: Stop
  Interface 2
    Altset 1
    Format: S16_LE
    Channels: 2
    Endpoint: 2 IN (ASYNC)
    Rates: 48000, 44100

If I use the default asound.conf above with no resampling I get the following shairport message but it seems to continue (albeit with no audio)

Can't set the D/A converter to 44100 -- set to 48000 instead./n

So I first tried with and without resampling to 44100 in ALSA by setting the plug rate to 44100 or 48000 and it didn't seem to make a difference to the stuttering. So decided to stick with 48000 and adjust for frames of that size, which then got things working smoothly.

Interestingly audio being played directly through mopidy from local files or streamed radio 'just worked' no matter if I resampled or not.

[mikebrady]

Thanks for the interesting update. I guess that the difference between Shairport Sync and Mopidy is related to the fact that, to maintain synchronisation, Shairport Sync is continually checking the latency of the output device whereas Mopidy isn't. It might be worth looking to see if the checking could be done less frequently, or something, but that's a long way off just yet. Many thanks.

[bboffey]

Sounds like I've not missed anything obvious then. I think as a next step I'll speak to the Pi MusicBox guys and look at adding a latency option to the configuration. Shouldn't be too difficult from what I've seen of the setup so far and will hopefully help others.

Thanks for the responses and the very cool software :) I'll mark this issue as closed.

[mikebrady]

Thanks

[bboffey]

Hello again Mike,

I may try and morph this into a feature request... :)

So right now I've got the above magic fudge in /etc/asound.conf but this is explicitly to get shairport-sync to work, other players (like mpd, mopidy, etc) don't need it and it seems like a not ideal overhead to have all the time.

Would you be open to exposing additional alsa configurations in /etc/shairport-sync.conf for things like period_size and buffer_size which would allow a configuration like this:

alsa = {
  output_device = "hw:1,0";
  mixer_control_name = "Master";
  period_size = 960;
  buffer_size = 9600;
  rate = 48000;
};

If this is of no use to anyone but me and my awkward old USB DAC then no worries, but I thought it's worth discussing.

[mikebrady]

Thanks for the message.

What I think you've done at #167 (comment) above is create a virtual alsa device and made it the default. Then, Shairport Sync is outputting at 44,100 stereo samples per second into it, and it is converting this on the fly to 48,000 stereo samples per second to feed to the USB DAC.

I would be reluctant to involve Shairport Sync in creating a virtual alsa device like this, TBH – I think this is something best left to the user.

Many a better approach would be to write up a quick note about the technique and put it into the new Troubleshooting page. What to you think?

[joerg-krause]

Setting period and buffer size requires an alsa dmix plugin as you did in your asound.conf. This might not be configured for all users. Also, it is very common to adjust these values in asound.conf, so I agree with Mike here.

[bboffey]

Thanks for the replies. Apologies if I wasn't clear, I have indeed needed to create a virtual alsa device/dmix plugin to get Shairport Sync to work on my Raspberry Pi with various distributions (PiMusicBox/Volumio/etc).

My concern is that this is a special case required only for Shairport Sync to work, hence why I suggested a method for it to be handled within Shairport Sync. This would keep things isolated and clean in terms of (external) implementation and I think make handling of this special case far easier in terms of changes to things like Volumio/PiMusicBox. Other sources/players such as mpd/mopidy/aplay work without the adjustment of period and buffer so having the fudge in places globally also just seems like overkill.

The conversion of 44.1k to 48k is a bit of a red herring, this is not absolutely necessary in my testing of the hardware I'm using, but it seemed to be the right thing to do from the capabilities it reported, so I included it for completeness.

I guess I could create a virtual alsa device specifically for use by shairport (i.e. not set it as default), but I'm less certain support for this would be easily patchable into something like Volumio.

For me this problem is easy to solve on my setup my changing files manually and will be going away soon as I'm moving to using an iQAudio DAC now but it would be nice to tie up the loose ends especially for others. I completely understand not wanting to complicate Shairport Sync though Mike.

I'll definitely write something more concise and clear for the Troubleshooting page :)

[mikebrady]

Thanks for this contribution. Please open a new issue if necessary.