Had the same problem. It seems to come from XBMC requesting a period size and not checking to see if it actually got that size before telling alsa to start playing only after it received that much data. Basically, these onboard cards seem to only allow 5k or so buffer space. XBMC needs 6k for 6 channel audio (2k for stereo audio).
(m_dwPacketSize == 6k or so)
m_maxFrames = m_dwPacketSize
snd_pcm_hw_params_set_period_size_near(m_pPlayHandle, hw_params, &m_maxFrames, 0);
(nvidia hd audio returns ~5k here, making m_maxFrames that)
...
snd_pcm_sw_params_set_start_threshold(m_pPlayHandle, sw_params, m_dwPacketSize);
ALSA never gets 6k of audio in the 5k buffer, and therefore never starts playing.
The following patch fixed it for me, which globally reduces the buffer requirements:
Code:
XBMC/xbmc/cores/AudioRenderers/ALSADirectSound.cpp
73c73
< m_dwPacketSize = iChannels*(uiBitsPerSample/8)*512;
---
> m_dwPacketSize = iChannels*(uiBitsPerSample/8)*64;
229c229
< m_maxFrames = m_dwPacketSize ;
---
> m_maxFrames = m_dwPacketSize*2 ;
233c233
< m_BufferSize = snd_pcm_bytes_to_frames(m_pPlayHandle,m_dwPacketSize * 10); // buffer big enough - but not too big...
---
> m_BufferSize = snd_pcm_bytes_to_frames(m_pPlayHandle,m_dwPacketSize * 20); // buffer big enough - but not too big...
This is most likely not the proper way to fix it though -- XBMC should probably check to see if it got the period size it requested, or at least check to see if theres enough to start playing. I'm not sure on the implications of lowering the packet size throughout the program either, likely causes just a bit more cpu usage. Also, changing the buffer size is probably not necessary. I'll leave it to the devs to make a proper fix but this may save them a little bit of narrowing down where the problem is.