[AE][ALSA] Fix support for cards with hardware mixer #1909

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
8 participants
Contributor

manio commented Dec 9, 2012

Cards with hardware mixer doesn't need to use dmix at all.
Old behavior leads to problem with playing non 48kHz audio on
multispeaker configuration.
On Audigy wrong device was opened according to frequency:
44.1kHz: front:CARD=Audigy,DEV=0
48.0kHz: sysdefault:CARD=Audigy

This patch enables check for hardware mixer availability and
open PCM device with taking it into account.

More information: http://trac.xbmc.org/ticket/13381

@manio manio [AE][ALSA] Fix support for cards with hardware mixer
Cards with hardware mixer doesn't need to use dmix at all.
Old behavior leads to problem with playing non 48kHz audio on
multispeaker configuration.
On Audigy wrong device was opened according to frequency:
44.1kHz: front:CARD=Audigy,DEV=0
48.0kHz: sysdefault:CARD=Audigy

This patch enables check for hardware mixer availability and
open PCM device with taking it into account.

More information: http://trac.xbmc.org/ticket/13381
e87d8a8
Owner

Memphiz commented Dec 9, 2012

This looks coding wise. Not sure about the semantics though - but i bet an AE dev might comment.

Member

anssih commented Dec 9, 2012

Thanks for the patch. However, the hardware mixer check is incorrect and instead checks for devices that have subdevices.

The solution seems to otherwise be valid, though, in that for devices with hw mixer we don't need to care about dmix sample rate. I'll try to look for other solutions ASAP (today or tomorrow), but feel free to update your patch if you find another solution :)

Also, the semantics change a bit so you might want to update comments and the name of "preferDmixStereo". In addition, you can't really really on enumeration information in Initialize() since users may use custom non-enumerated devices. You need to check for hw mixing in Initialize() (unless a bigger restructuring of the code is made).

how about moving this to a static member var ? See static CAEDeviceInfo m_info; in AESinkAUDIOTRACK.h

+1

cosmetic alignment of comment

Owner

manio replied Dec 9, 2012

I did it similarily as the rest of variables: so it's double tab (exactly like a line above). But as we know the tabs depends on editor options...

xbmc source code never used tabs :) we use spaces, any code that has tabs in it is costemtically wrong..

I'll fix these stray tabs later so ok for now.

Contributor

manio commented Dec 9, 2012

@anssih
I did the mixer check according to info i googled out, eg:
http://forums.gentoo.org/viewtopic-t-696866.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2007-May/001019.html
The check is based on subdevices count (in my case it is 32). I was also asking on #alsa to confirm it, but no reply, so i leave it as it is.
I'll wait for your solution, you surely do it better :)

Member

anssih commented Dec 9, 2012

@manio OK, I will double check later when I'm home, maybe the subdevices work differently than I remember :)

Member

anssih commented Dec 10, 2012

So.. subdevices > 1 can mean that there is a hw mixer, but it can also mean that different subdevices are wired to different connectors. The way ALSA uses them is defined in the card .conf file.

I didn't find any non-hacky way to detect dmix, so personally I'm compelled to remove the "try-to-skip-dmix-when-playing-stereo-non-48kHz-audio" hack (uses "front" instead of "default" device in such cases) altogether. This way, if the selected ALSA device is configured to have dmix, dmix will be used (this doesn't affect surround audio, since for those ALSA surroundXX are tried first by default, and those never have dmix; similarly, this doesn't affect HDMI nor S/PDIF that don't have dmix either).
This is also the way it worked in Eden and how it works in most other applications.

(this hack was originally added by me, since originally the AE ALSA sink always bypassed dmix, which was problematic - In fixing that, I tried to have a middle ground between original AE ALSA sink behavior and Eden behavior, but clearly it still causes issues)

@DDDamian @gnif Would you be OK with that?

Contributor

DDDamian commented Dec 12, 2012

@anssi - from my perspective of course and thank you.

Hm attached a log from my side:

http://pastebin.com/mxvfMsRA

Audio worked fine on first channels, second and following my audio was dead till reboot.

Contributor

manio commented Feb 15, 2013

@anssih
bump! any news on this? :)

Are we sure, it really has one there?

Member

anssih commented Mar 11, 2013

I'm really sorry, again, for the long delay. There is now a PR #2422 which supersedes this one. Please test.

anssih closed this Mar 11, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment