Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: missing /dev/dsp* after upgrade to 10.10

  1. #11
    Join Date
    Feb 2007
    Location
    Gray, TN, USA
    Beans
    155
    Distro
    Xubuntu 10.10 Maverick Meerkat

    Re: missing /dev/dsp* after upgrade to 10.10

    Quote Originally Posted by sceo View Post
    Interesting, I also have a streamzap and had problems. I used #49 in this thread:
    http://ubuntuforums.org/showthread.php?t=1595018&page=5

    ...FWIW. But if blacklisting works, that is much easier. I may follow suit; let me know how it goes!
    Blacklisting didn't work. The streamzap module loads anyway, in spite of blacklisting. Recompiling the kernel without its built-in streamzap support, however, does work. Kernel .config attached above has been updated.

    Hopefully, limiting our hacks to the kernel config will allow us later to avoid having to undo a bunch of hacks in a bunch of places we're bound to forget by the time the /dev/dsp issue and the lirc issue are both resolved satisfactorily. When those are resolved, I do intend to resume Canonical-maintained kernels on my system.
    Q: How many ADD kids does it take to screw in a lightbulb?
    A: Hey! Let's go ride bikes!

  2. #12
    Join Date
    Feb 2008
    Beans
    7

    Re: missing /dev/dsp* after upgrade to 10.10

    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":

    1. The sound can play normally. This means that ALSA is working properly. MythTV's backend must be misconfigured or broken.
    2. 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.
    3. 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).
    4. 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.

  3. #13
    Join Date
    Aug 2009
    Beans
    1,419

    Re: missing /dev/dsp* after upgrade to 10.10

    Myth .24 supports pulseaudio, and you no longer have to have OSS to run myth. I cover setting up myth without OSS here.

  4. #14
    Join Date
    Feb 2007
    Location
    Gray, TN, USA
    Beans
    155
    Distro
    Xubuntu 10.10 Maverick Meerkat

    Re: missing /dev/dsp* after upgrade to 10.10

    Quote Originally Posted by thatguruguy View Post
    Myth .24 supports pulseaudio, and you no longer have to have OSS to run myth. I cover setting up myth without OSS here.
    Cool. That takes care of 1/2 the problem. However, Pulse won't provide me an option to choose my S/PDIF device integrated on my Nforce4 board as my playback device. It'll do stereo, or analog 5.1, but will do neither optical nor digital coaxial. So Pulse is not an option for me yet.

    Thanks for the link to the myth pulseaudio info though! I'll hang onto it.
    Q: How many ADD kids does it take to screw in a lightbulb?
    A: Hey! Let's go ride bikes!

  5. #15
    Join Date
    Jun 2009
    Beans
    2

    Re: missing /dev/dsp* after upgrade to 10.10

    You guys have saved me a lot of trouble!

    I am currently away @ College using a VirtualBox to work the kinks out of a setup back home. I have a DC60 Model EasyCap and I've been trying to get the dang thing to take input from its stereo input, until today, I hadn't found a definite answer and this .config file should do wonders on both my VirtualBox Test environment as well as the real Backend back home

    Thanks, calraith, for making this easier on all of us who have legacy devices and optimal oss drivers!!!

  6. #16

    Re: missing /dev/dsp* after upgrade to 10.10

    This situation is much worse than most realize. In the Ubuntu repository are a great many legacy software programs which were hard-coded to use /dev/dsp to access the sound card. All these apps are now broken. Since they are hard-coded to use /dev/dsp there is no way short of re-writing the code to make them work with Ubuntu 10.10 and beyond.

    At this point, the only thing I can say is "BEWARE THE UBUNTU REPOSITORY" because it contains a significant number of broken programs.

    This type problem is not tagged by any "missing dependency" warnings, so you must download and install the programs in order to find that they don't work.
    POSIX

  7. #17
    Join Date
    Jan 2011
    Beans
    9

    Re: missing /dev/dsp* after upgrade to 10.10

    Could the solution to this issue be as simple as creating a /dev/dsp and symbolically linking it to the correct device, in my case, /dev/snd/controlC0?

  8. #18
    Join Date
    Jan 2011
    Beans
    36

    Angry Re: missing /dev/dsp* after upgrade to 10.10

    Quote Originally Posted by arvevans View Post
    This situation is much worse than most realize. In the Ubuntu repository are a great many legacy software programs which were hard-coded to use /dev/dsp to access the sound card. All these apps are now broken. Since they are hard-coded to use /dev/dsp there is no way short of re-writing the code to make them work with Ubuntu 10.10 and beyond.

    At this point, the only thing I can say is "BEWARE THE UBUNTU REPOSITORY" because it contains a significant number of broken programs.

    This type problem is not tagged by any "missing dependency" warnings, so you must download and install the programs in order to find that they don't work.


    .WINE WXTOIMG (worked in u9.10) included in this software list.
    cj

  9. #19
    Join Date
    Jun 2008
    Beans
    35

    Re: missing /dev/dsp* after upgrade to 10.10

    I read this thread and was terrified. I'm not equipped to go fooling with the kernel. So....for anyone who's like me, here's what I did. I'm running my sound through VLC. It's not ideal, but it does not involve me wrecking my system. Just thought I'd mention this.

  10. #20
    Join Date
    May 2006
    Location
    Ciudad de México
    Beans
    18
    Distro
    Ubuntu Gnome

    Re: missing /dev/dsp* after upgrade to 10.10

    @kf7nnz Did you try it? How did it work out? Please, tell us more.

Page 2 of 3 FirstFirst 123 LastLast

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •