analog multichannel audio and hda nvidia
#16
Curiously new builds have code in them to do downmixing based on settings.

Downmixed, it works fine.

I made a temporary change to settings.cpp so it never does downmixing (after failing to get it to read my advancedsettings.xml value). With multichannel, it still freezes.
Reply
#17
See => http://forum.xbmc.org/showthread.php?tid=36982

It is a feature suggestions because it is not supported yet, its a legacy from the Xbox days.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#18
Gamester17 Wrote:See => http://forum.xbmc.org/showthread.php?tid=36982

It is a feature suggestions because it is not supported yet, its a legacy from the Xbox days.

But using my SoundBlaster Live 5.1, I've got perfect analogue 5.1 in DVDs etc (with multi-channel enabled in xbmc).
This seems to be a bug pertaining to the dvd audio decoder/whatever in XBMC and the Realtek/Intel HD cards (snd-hda-intel).

EDIT: To clarify:
In pre-current SVN versions, I commented out a conditional line in ALSADirectSound.cpp downmixing. This made 5.1 work fine, as far as I was are of (5.1 dolby speaker tests worked, dvds were clearly surround, etc). That was using a SoundBlaster Live! card.
In current SVN, I need to set one of the advancedsettings = true (analogmultichannel I believe). I haven't tried this with SBLive, but I have with the Intel card. As soon as 5.1 is enabled, the bug reported earlier in this thread appears.
Reply
#19
Well i gave up on using the onboard nvidia HD cos it just wont work with analog multichannel enabled in advancedsettings.xml, i have no clue on the reason it just freezes the video. Recently i got an external usb Aureon 5.1 mk2 soundcard. Analog 5.1 now works perfectly just like the soundblaster card. Using rev 16869

My advancedsettings.xml
Code:
<advancedsettings>
    <audio>
        <analogmultichannel>true</analogmultichannel>        
    </audio>
</advancedsettings>

cheers
Reply
#20
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.
Reply
#21
flack70 I could kiss you. Laugh

This works. This was the last thing that I needed to make XBMC perfect.

Please submit this as a patch on trac so this can go into svn or at least make the devs find a better solution.

Many many thanks
Reply
#22
flack70 Wrote: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.

flack70 - This worked for me as well. Thank you!!
Reply
#23
Can some explain how I apply this patch?
Reply
#24
flack70 Wrote: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.

Any chance a dev could have a look at the patch. Maybe there is a way it could be added into the svn? Or would it cause problems with other setups?

cheers.
Reply
#25
pls open a ticket on trac
Reply
#26
http://trac.xbmc.org/ticket/5801
Reply
#27
Thanks for this fix. 5.1 for movies is working fine. (Intel HDA, ACL889, Alsa 1.0.19) But:For me this patch breaks paplayer (no audio, visualisations standing still). Anyone else having this issue?
Reply

Logout Mark Read Team Forum Stats Members Help
analog multichannel audio and hda nvidia1