ASUS Xonar D2X & PulseAudio

[SilentStorm]

I'm using Debian Testing with KDE desktop, and having problem with PulseAudio's sound card detection.

The system I'm using has three sound sinks (or cards if you wish):
- nVidia GTX680's sound output over DisplayPort.
- Intel's on board HD audio.
- ASUS Xonar D2X on PCIe (CMedia CM8788) [Preferred & default card].

All of the cards are well supported under Linux, ALSA and PulseAudio, however PulseAudio is sometimes do not detecting my soundcard and revert to one of the other cards as it pleases. The problem started with a kernel update (I don't remember the exact version). What I've diagnosed is as follows:
- Card is always operational. Present in lspci, initialized correctly (D2X has hard relays as mute switches and I hear the distinctive CLACK sound when the card is initialized).
- ALSA always detecting and calling the card settings from persistence as it should, I verified with ALSA mixer.
- Deleting PulseAudio settings and restarting daemon generally has no help.
- When card is not detected it's completely absent from PulseAudio's configuration and configuration database.
- I sometimes need to shutdown and restart the PC two to three times to get the sound card back.
- It's more likely occur if I log-on to my pc late (press the power button, get a cup of tea, drink some, wander off and login).
- There's no terse/warning/error logs anywhere. Everything is working as it should on paper, so I cannot debug the problem.

Did anyone experience anything like this? I have the ability to debug and patch the code if necessary, and if someone can at least show me the right place for discussing this stuff I'd be grateful.

Thanks in advance,

Best regards.

[bw123]

...
The problem started with a kernel update (I don't remember the exact version
...

If you could confirm this, and find out which kernel update it was, that would be a clue? Then you could check bug reports and report it or confirm the bug if it is already reported. By using reportbug the devs will have all your hardware/system info in a form they can refer to.

That's what you guys on testing are supposed to do?

[SilentStorm]

...
The problem started with a kernel update (I don't remember the exact version
...

If you could confirm this, and find out which kernel update it was, that would be a clue? Then you could check bug reports and report it or confirm the bug if it is already reported. By using reportbug the devs will have all your hardware/system info in a form they can refer to.

I would try, however the problem is not perfectly reproducible, hence it needs time to test.

That's what you guys on testing are supposed to do?

You're right however, this is not the only Linux machine I'm using or supporting. I always do not have the luxury to test some bugs for months. A 1K server cluster, and said cluster's users do not have the time to wait for me to test some bugs.

That's why I asked people if they experienced something similar. If they didn't I will dig deeper. I need to use my time wisely.

[GarryRicketson]

Did anyone experience anything like this? I have the ability to debug and patch the code if necessary, and if someone can at least show me the right place for discussing this stuff I'd be grateful.

from: https://wiki.debian.org/DebianTestingHow to use Debian (next-stable) Testing

First thing is to assess the current state of testing. Have a look at the recent topics in the debian-testing mailing list archive and the Status/Testing Wiki-Page. Besides using these specific resources you can also use the general debian-user and debian-devel mailing lists, IRC channels #debian or #debian-next, and of course the debian bug tracker. You may also have a look at the DebianDesktopHowTo.

I always do not have the luxury to test some bugs for months. A 1K server cluster, and said cluster's users do not have the time to wait for me to test some bugs.

Also https://www.debian.org/doc/manuals/debi ... ng.en.html

If you are running a server, especially one that has strong stability requirements or is exposed to the Internet, install stable. This is by far the strongest and safest choice.

I need to use my time wisely.

Me too, and that is why I don't do much with Debian Testing, all though I do appreciate the work those that are developing Debian and use the testing version, to test everything. I don't have the time, nor the skill , to spend hours searching bug reports, etc, to try to figure out what is wrong.
On my servers, I use stable , well tested systems, same reason, I don't have the time to spend making repairs and adjustments , testing new packages and updates.

[SilentStorm]

First thing is to assess the current state of testing. Have a look at the recent topics in the debian-testing mailing list archive and the Status/Testing Wiki-Page. Besides using these specific resources you can also use the general debian-user and debian-devel mailing lists, IRC channels #debian or #debian-next, and of course the debian bug tracker. You may also have a look at the DebianDesktopHowTo.

Actually, I've looked around and didn't find anything useful. I've sent two posts. One to here, other one directly to pulseaudio-discuss. Debian IRC channels do not answer that fast, and I cannot monitor them all day after asking something. I may bother people in Debian mailing lists next, but I actually thought that there will be knowledgeable people too.

Me too, and that is why I don't do much with Debian Testing, all though I do appreciate the work those that are developing Debian and use the testing version, to test everything. I don't have the time, nor the skill , to spend hours searching bug reports, etc, to try to figure out what is wrong.
On my servers, I use stable , well tested systems, same reason, I don't have the time to spend making repairs and adjustments , testing new packages and updates.

I do not use testing on my servers. The servers I use are strictly stable. My desktop hardware is too modern for stable generally, and I'm using testing for ~15 years I think. This is one of the rare bugs I encountered in the last years. When I encounter something generally the patch is already in unstable, so I don't bother people again for somehting already fixed.

To be honest, having the skill and the means to write/debug/patch any kind of software is moot if you don't have enough time. My day job, personal R&D (I develop high performance algorithms and some pet projects) and some social life eats my all free time, so I cannot spend enough time fixing Debian. I'd rather like to do more, but time will tell...

[bw123]

Congrats on the busy schedule, and social life too hey that sounds really fun. I'm hoping someone will spend the time getting pulseaudio fixed up in buster so I can use it. I gave up on it for stretch. I don't really find an audio server necessary for a laptop or desktop so I just run alsa. Works fine on plasma in stretch if you install kmix and either of the phonon-backend pkgs, not sure about browser support though. Maybe that could work for you?

[SilentStorm]

Congrats on the busy schedule, and social life too hey that sounds really fun. I'm hoping someone will spend the time getting pulseaudio fixed up in buster so I can use it. I gave up on it for stretch. I don't really find an audio server necessary for a laptop or desktop so I just run alsa. Works fine on plasma in stretch if you install kmix and either of the phonon-backend pkgs, not sure about browser support though. Maybe that could work for you?

Thanks! It is generally fun, but sometimes it becomes exhausting, so its sustainability is a huge, and admittedly very rewarding, life management exercise by itself. Hope you have a better and more enjoyable life than me .

I like PulseAudio's promises, but sometimes find it a little quirky. Like systemd, it carries its developers' DNA .

BTW, I debugged and solved the problem, and the reason is something between strange and hilarious.
With a spark of an idea, I logged out, closed all user processes, and logged in as my user from console. Fired PulseAudio with debug level verbosity. While digging the logs, I've found something about my primary card being busy. Someone had a similar issue and it turned out a package installed was allocating the card before PulseAudio starts.

Long time ago, I've installed SoundKonverter, and its suggestion Timidity (and its daemon) was also installed, however the problem was not present at that time. It turned out that Timidity was allocating the card exclusively somehow, and PulseAudio was tagging the card busy, and moving on during initialization. I've removed Timidity for now, but continue investigating it. I may not be able to patch it, but will try to bother right people if it's indeed a bug.

Addenda: Somehow has filed a bug for Timidity & PulseAudio compatibility in Debian bug tracker (https://bugs.debian.org/cgi-bin/bugrepo ... bug=563252). It's a nice read.

Thanks for all the chat,

Regards

[sunrat]

Have you done a full-upgrade lately? There was a bug with Timidity in testing and sid about three months ago but it was fixed almost as long ago.
https://bugs.debian.org/cgi-bin/bugrepo ... bug=901931

I think the problem is related to the fact that, on a Debian system
running pulseaudio, timidity-daemon still tries to add the "timidity"
user to the "audio" group. It shouldn't. On such systems (at least those
where the pulseaudio daemon is not being run system-wide) the "audio"
group should be empty. This is well explained here:
https://www.freedesktop.org/wiki/Softwa ... fectSetup/
section «Should users be in the "audio" group?».

Emptying the "audio" group and rebooting the box fixed the issue.

(To whoever might read: only do this after taking precautions)

It's exciting running testing, you never know what surprises are around the corner.

[SilentStorm]

Have you done a full-upgrade lately? There was a bug with Timidity in testing and sid about three months ago but it was fixed almost as long ago.
https://bugs.debian.org/cgi-bin/bugrepo ... bug=901931

I think the problem is related to the fact that, on a Debian system
running pulseaudio, timidity-daemon still tries to add the "timidity"
user to the "audio" group. It shouldn't. On such systems (at least those
where the pulseaudio daemon is not being run system-wide) the "audio"
group should be empty. This is well explained here:
https://www.freedesktop.org/wiki/Softwa ... fectSetup/
section «Should users be in the "audio" group?».

Emptying the "audio" group and rebooting the box fixed the issue.

(To whoever might read: only do this after taking precautions)

Actually, I upgrade my system regularly. I'd try to reinstall timidity when I get home and have some time. Thanks for the heads-up!

It's exciting running testing, you never know what surprises are around the corner.

Indeed, it's a very fun ride. However it rarely gets violent like unstable

[sunrat]

Actually, I upgrade my system regularly. I'd try to reinstall timidity when I get home and have some time. Thanks for the heads-up!

You only need Timidity if you use it to play midi files. Check if timidity user is a member of audio group as that's what was reported to cause the problem (should have been removed when you uninstalled timidity).

Code: Select all

awk -F: '/^audio/ {print $4;}' /etc/group

It's exciting running testing, you never know what surprises are around the corner.

Indeed, it's a very fun ride. However it rarely gets violent like unstable

Sometimes the reverse is true. If a problem package makes it through to testing, it may take quite some time for a fix to arrive after it's been fixed in unstable.

[SilentStorm]

You only need Timidity if you use it to play midi files. Check if timidity user is a member of audio group as that's what was reported to cause the problem (should have been removed when you uninstalled timidity).

I'm an old folk. Started this stuff with C64. I'm always partial to demoscene, mod files, midi and other ancient artifacts of pushing incapable computers to its limits. That's why I love developing high performance algorithms

Sometimes the reverse is true. If a problem package makes it through to testing, it may take quite some time for a fix to arrive after it's been fixed in unstable.

Yep, you're right. Similarly, following Firefox from unstable is a wise idea. Debian has many intricacies, and this post space is very very limited for writing them all. However, isn't it the part of the journey, and one of the details which makes the whole journey much more fun?

[sunrat]

Similarly, following Firefox from unstable is a wise idea.

Haha, Firefox from sid upgrade today has a bug where bookmarks and history disappear. I know because I unwisely upgraded it in my siduction install, ignoring upgrade bug warnings. It's my reserve system so no biggie.

[SilentStorm]

Similarly, following Firefox from unstable is a wise idea.

Haha, Firefox from sid upgrade today has a bug where bookmarks and history disappear. I know because I unwisely upgraded it in my siduction install, ignoring upgrade bug warnings. It's my reserve system so no biggie.

That's very strange and sad.

Debian Mozilla Team is "releasing" to unstable. So I'm heeding their advice actually. See http://mozilla.debian.net/. Debian Mozilla Team puts betas to Debian/Experimental. I didn't have any problems for ~1.5 years IIRC. Currently I'm running 62.0.2 from Debian/unstable repository.

[sunrat]

I just upgraded my other daily driver system. Same OS (siduction which is basically Debian Sid) and Firefox is fine. The reserve system hadn't been upgraded for a while and those things usually sort themselves out. Weird though.

[SilentStorm]

I just upgraded my other daily driver system. Same OS (siduction which is basically Debian Sid) and Firefox is fine. The reserve system hadn't been upgraded for a while and those things usually sort themselves out. Weird though.

Recently, Firefox has removed description field from the bookmarks data structure. Maybe something went wrong during the migration. This kind of stuff can happen if the database is very old. I'm using Firefox sync between my installations too. It's very handy.

[sunrat]

It was fixed in upgrade today to FF 62.0.3.

Anyway, we have drifted far from the original topic. Glad your sound card is working!