Created attachment 121773 [details] Output of alsa-info.sh Pulseaudio sees only hw:1 and hw:2 in system, not hw:0 (a Soundblaster), while the necessary modules are loaded, and the device works when tested in Yast (openSuse's admin tool). I entered https://bugzilla.opensuse.org/show_bug.cgi?id=965328 where it has been handled by Takashi Iwai. On his advice I report the problem here. I'll add a few attachments which are hopefully useful.
Created attachment 121774 [details] Output of pulseaudio -vvvv
You have to specify correct extin and extout according to your model and live drive https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/Documentation/sound/alsa/ALSA-Configuration.txt
Module for EMU10K1/EMU10k2 based PCI sound cards. * Sound Blaster Live! * Sound Blaster PCI 512 * Emu APS (partially supported) * Sound Blaster Audigy extin - bitmap of available external inputs for FX8010 (see bellow) extout - bitmap of available external outputs for FX8010 (see bellow) seq_ports - allocated sequencer ports (4 by default) max_synth_voices - limit of voices used for wavetable (64 by default) max_buffer_size - specifies the maximum size of wavetable/pcm buffers given in MB unit. Default value is 128. enable_ir - enable IR This module supports multiple cards and autoprobe. Input & Output configurations [extin/extout] * Creative Card wo/Digital out [0x0003/0x1f03] * Creative Card w/Digital out [0x0003/0x1f0f]. * Creative Card w/Digital CD in [0x000f/0x1f0f] * Creative Card wo/Digital out + LiveDrive [0x3fc3/0x1fc3] * Creative Card w/Digital out + LiveDrive [0x3fc3/0x1fcf] * Creative Card w/Digital CD in + LiveDrive [0x3fcf/0x1fcf] * Creative Card wo/Digital out + Digital I/O 2 [0x0fc3/0x1f0f] * Creative Card w/Digital out + Digital I/O 2 [0x0fc3/0x1f0f] * Creative Card w/Digital CD in + Digital I/O 2 [0x0fcf/0x1f0f] * Creative Card 5.1/w Digital out + LiveDrive [0x3fc3/0x1fff] * Creative Card 5.1 (c) 2003 [0x3fc3/0x7cff] * Creative Card all ins and outs [0x3fff/0x7fff]
One application is using the card **** List of PLAYBACK Hardware Devices **** card 0: Live [SB Live! 5.1], device 0: emu10k1 [ADC Capture/Standard PCM Playback] Subdevices: 31/32 Pulseaudio udev detect expect all devices are closed
https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/module-udev-detect.c?id=d6fb8d10819bebc1cee203de7330cceeafde9fed
As Raymond said, something else is using the sound card. You can use "lsof /dev/snd/pcm*" to see what program that is.
I'll check both (determine extins and extouts, and lsof) this afternoon (CEST).
I: [pulseaudio] module.c: Loaded "module-alsa-card" (index: #7; argument: "device_id="2" name="pci-0000_00_14.2" card_name="alsa_card.pci-0000_00_14.2" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes card_properties="module-udev-detect.discovered=1""). I: [pulseaudio] module-udev-detect.c: Card /devices/pci0000:00/0000:00:14.2/sound/card2 (alsa_card.pci-0000_00_14.2) module loaded. D: [pulseaudio] module-udev-detect.c: /dev/snd/controlC0 is accessible: yes D: [pulseaudio] module-udev-detect.c: /devices/pci0000:00/0000:00:14.4/0000:02:06.0/sound/card0 is busy: yes Since the sound card support hardware mixing, there are still 31 subdevices left for playback by other alsa application but pulseaudio just assume the card is busy when pcm is not closed
The subdevice is blocked by the timidity-daemon: lsof /dev/snd/pcm* lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME timidity 709 root mem CHR 116,3 11646 /dev/snd/pcmC0D0p timidity 709 root 4u CHR 116,3 0t0 11646 /dev/snd/pcmC0D0p I could disable this daemon, but I would rather keep it running... From the last comment from Raymond I understand that this habit of pulseaudio to disregard the device if only one of the 32 subdevices is in use, is undesirable. Am I right in that conclusion? I have yet to figure out what the extins and extouts from the device are. Not sure if I can manage to do so this evening.
(In reply to Jogchum Reitsma from comment #9) > The subdevice is blocked by the timidity-daemon: > > lsof /dev/snd/pcm* > lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs > Output information may be incomplete. > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > timidity 709 root mem CHR 116,3 11646 /dev/snd/pcmC0D0p > timidity 709 root 4u CHR 116,3 0t0 11646 /dev/snd/pcmC0D0p > > I could disable this daemon, but I would rather keep it running... It seems to be running as root. Can you run it as your normal user instead? Hopefully timidity isn't hardcoded to use hw:0 or some similar alsa device, so that it can run on top of pulseaudio. > From the last comment from Raymond I understand that this habit of > pulseaudio to disregard the device if only one of the 32 subdevices is in > use, is undesirable. > > Am I right in that conclusion? PulseAudio doesn't support taking advantage of hardware mixing when it's available. There aren't very strong arguments for adding that support either, so such functionality isn't planned to be added. > I have yet to figure out what the extins and extouts from the device are. > Not sure if I can manage to do so this evening. FWIW, I don't know what extins and extouts are, and how they are relevant here.
Thanks for your (and Raymond's) quick responses! Timidity is a daemon, started as a system service in the boot process. That's why the process runs as root. So if you mean to test the behavior when started as a normal user, that can be done of course. Please let me know if that's what you mean. But normal behavior is starting the daemon on boot, as root. The extin and extout is asked by Raymond in comment #2. There must be many soundblasters and other cards around with mixing capabilities. I can hardly believe that I am the only one that uses that functionality in Linux-land? To be more precise, mixing is not what is done here: the timidity-daemon (used to play midi-files) lies "sleeping" till a midi-file has to be played. It is - in my use case - never really mixed with other sound sources. Still one would want to play a Youtube-movie, a CD or something on disk, without stopping the timidity-daemon, and starting that anew to play a midi-file. But there must be many use cases that do really mixing sounds; otherwise Soundblaster wouldn't bother to build it, I would say.
As your emu10k1 have hardware wavetable synth of 64 voices , you can use asfxload to load sf2 soundfont and don't need to use software synth timidity
(In reply to Jogchum Reitsma from comment #11) > Thanks for your (and Raymond's) quick responses! > > Timidity is a daemon, started as a system service in the boot process. > That's why the process runs as root. > > So if you mean to test the behavior when started as a normal user, that can > be done of course. Please let me know if that's what you mean. I mean that if you can configure timidity to run not as root, but as your regular user, you should be able to make timidity and pulseaudio cooperate, by making timidity connect to pulseaudio instead of using the sound card directly. > But normal behavior is starting the daemon on boot, as root. I guess you mean it's normal for timidity. It's certainly not normal for audio programs in general, for a good reason. A daemon that keeps the sound card open all the time is very bad, if you want to use the sound card with any other software. > The extin and extout is asked by Raymond in comment #2. > > There must be many soundblasters and other cards around with mixing > capabilities. I can hardly believe that I am the only one that uses that > functionality in Linux-land? It's very rare to want to use hardware mixing. I can't name any good reason why that would be required, and indeed many (I'd guess most) sound cards don't support it at all. > To be more precise, mixing is not what is done > here: the timidity-daemon (used to play midi-files) lies "sleeping" till a > midi-file has to be played. It is - in my use case - never really mixed with > other sound sources. Still one would want to play a Youtube-movie, a CD or > something on disk, without stopping the timidity-daemon, and starting that > anew to play a midi-file. > > But there must be many use cases that do really mixing sounds; otherwise > Soundblaster wouldn't bother to build it, I would say. I don't know why Soundblaster cards bother with hardware mixing nowadays. In ancient history that was probably done to save some CPU, and maybe also the reality was that operating systems didn't provide audio mixing capabilities.
You just need to start timidity after pulseaudio probe your sound cards, timidty use default subdevice -1 which mean any available subdevice
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/conf/alsa.conf;hb=HEAD defaults.pcm.device 0 defaults.pcm.subdevice -1
(In reply to Tanu Kaskinen from comment #13) > > I mean that if you can configure timidity to run not as root, but as your > regular user, you should be able to make timidity and pulseaudio cooperate, > by making timidity connect to pulseaudio instead of using the sound card > directly. OK, I'll try that. > > > I guess you mean it's normal for timidity. It's certainly not normal for > audio programs in general, for a good reason. A daemon that keeps the sound > card open all the time is very bad, if you want to use the sound card with > any other software. Indeed that's what I mean: normal for timidity. I don't know how other sound daemons, if existent, behave or should behave... > > > It's very rare to want to use hardware mixing. I can't name any good reason > why that would be required, and indeed many (I'd guess most) sound cards > don't support it at all. I cannot either (as said, I don't really mix sounds at all), except that it's odd that a major player in the market designs hardware that makes it possible, if there's no use for it. > > I don't know why Soundblaster cards bother with hardware mixing nowadays. In > ancient history that was probably done to save some CPU, and maybe also the > reality was that operating systems didn't provide audio mixing capabilities. Well, if I can indeed persuade timidity to run as normal user instead of root, the problem may be gone for me. Don't know if that is possible, because it is started as a service on boot. Or, skip timidity al all and use the hardware wavetable synth from the card, as Raymond suggests in comment #12. I'll try that as a first step. Thanks so far!
(In reply to Raymond from comment #15) > http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/conf/alsa.conf; > hb=HEAD > > defaults.pcm.device 0 > defaults.pcm.subdevice -1 Thanks, I'll try that. Will be in the afternoon/evening (CEST) though.
I dis-activated timidity, and now it works. I still have to follow Raymonds suggestion in comment #12, but that is for later. Thanks for all your help and explanations! I set status to Resolved/Notabug.
busy = is_card_busy(path_get_card_id(d->path)); - pa_log_debug("%s is busy: %s", d->path, pa_yes_no(busy)); + pa_log_info("%s is busy: %s", d->path, pa_yes_no(busy)); if (!busy) { The busy status should be info instead of debug since it skip the busy card but repport found 3 cards D: [pulseaudio] module-udev-detect.c: /devices/pci0000:00/0000:00:14.4/0000:02:06.0/sound/card0 is busy: yes I: [pulseaudio] module-udev-detect.c: Found 3 cards.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.