Is it possible to get mythbackend working with the ALSA devices at all? Is that functionality completely broken? I've also only used the /dev/dsp* devices in the past. I'd tried ALSA devices before, but never got them working with the backend. I had hoped it would be working by now since they took the /dev/dsp* devices away in Ubuntu 10.10, but I still can't get ALSA sound to work with mythbackend.
I can record audio from ALSA devices using the "arecord" utility, even when mythbackend is running, so I get the feeling the backend is not even opening the audio device. Here's what I do to test that ALSA is working:
Code:
user@host:~$ arecord -f dat -D hw:0,0 testfile.wav
Recording WAVE 'testfile.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
^CAborted by signal Interrupt...
user@host:~$ aplay testfile.wav
Playing WAVE 'testfile.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
user@host:~$
In the first command, I used the device name "hw:0,0" to directly communicate with the hardware and avoid PulseAudio. I let it run for a few seconds, then killed it. You can get an idea of the possible devices by looking at the output of "arecord -l" (lowercase "L") and "arecord -L" (uppercase). In my experimentation with various devices, I've found that there can be several results when I play the test file with "aplay":
- The sound can play normally. This means that ALSA is working properly. MythTV's backend must be misconfigured or broken.
- The "aplay" program runs for roughly the same length of time as "arecord" ran, but there's no sound. This probably means that you're recording on a device that has no input, has the wrong input selected, or is muted.
- The "aplay" program exits almost immediately. This means that it basically recorded a zero-length file because something was blocking "arecord" from working (usually PulseAudio, though if MythTV was working, it might block recording too).
- If "aplay" never exits on its own, then there is an audio output problem for ALSA programs. PulseAudio is probably blocking the output device.
I've been able to redirect ALSA output from mythfrontend through PulseAudio successfully since Ubuntu 9.10 or earlier by setting up an appropriate /etc/asound.conf file. Indeed, I think it's best to figure out how to have PulseAudio playing nicely with MythTV, since I still want other PulseAudio-aware programs on my MythTV machine for playing videos.
ALSA is divided into multiple pieces -- the userland programs and libraries, and the kernel audio drivers. What I've been able to do is tell the ALSA programs and libraries to send audio to a PulseAudio instead of talking to the hardware directly. PulseAudio then talks to the ALSA kernel drivers. To do this, you can set up /etc/asound.conf to redirect the "default" device to point at PulseAudio:
Code:
pcm.!default {
type pulse
}
ctl.!default {
type pulse
}
This seems to work with arecord/aplay for both recording and playing back audio. Multiple programs can be reading and writing ALSA's "default" device at the same time, something which is not possible when ALSA programs access my hardware directly.
To get mythfrontend working with ALSA audio redirected through PulseAudio, you formerly had to do this before running the program:
Code:
user@host:~$ export EXPERIMENTALLY_ALLOW_PULSE_AUDIO=1
before starting the frontend. However, the environment variable changed in Ubuntu 10.10, and you now need to do this instead:
Code:
user@host:~$ export DEBUG_PULSE_AUDIO_ALSA_EMULATION=1
Without this variable set, mythfrontend on Ubuntu 10.10 will normally suspend the pulseaudio daemon at startup, producing a message like this in its log messages:
Code:
2010-10-23 15:18:08.513 AudioPulseUtil: Suspend Success
However, if the variable is set, you should see this instead:
Code:
2010-11-21 12:56:33.200 WARNING:
2010-11-21 12:56:33.200 WARNING: ***Pulse Audio is running!!!!***
2010-11-21 12:56:33.200 WARNING:
2010-11-21 12:56:33.200 WARNING: You have told MythTV to ignore it.
2010-11-21 12:56:33.200 WARNING:
Depending on how you set this variable, whether in a script or elsewhere, you may need to restart the frontend for it to start working. It should be possible to get the frontend going with the audio output device set to "ALSA:default".
I still wanted to use direct access to the audio device for mythbackend, though. I tried using the device name "ALSA: I was worried that a device name like "ALSA:hw:0,0" might not get parsed correctly due to the extra colon character, so I created an alias in /etc/asound.conf like this:
Code:
pcm.direct {
type hw
card 0
device 0
}
ctl.direct {
type hw
card 0
}
arecord, aplay, and alsamixer all work correctly when passed the "-D direct" parameter with those lines added, but I can't get mythbackend to work with the audio input device set to "ALSA:direct".
I tried running mythbackend through the "aoss" utility, which sneakily intercepts any attempts to read/write /dev/dsp* files and redirects those requests to ALSA devices instead. It's always been a bit buggy, since it's playing a trick on these programs which some of them don't like. When I went and modified /etc/init/mythtv-backend.conf to replace the normal "exec" line with this:
Code:
exec /usr/bin/aoss /usr/bin/mythbackend --logfile /var/log/mythtv/mythbackend.log --user mythtv -v audio,libav
...and added these lines to /etc/asound.conf:
Code:
pcm.dsp0 {
type plug
slave.pcm "hw:0,0"
}
...I was able to see that MythTV was being partly tricked into thinking there was a /dev/dsp0 file. Unfortunately, the only sound I can get with aoss is static.
I guess I'll grudgingly try to build a new kernel with the ALSA OSS drivers included, but I'm not happy with that since I'll basically have to re-compile it every time a new kernel comes along, and they're pretty frequent these days...
Still, it seems to me that mythbackend is doing something wrong.
Bookmarks