missing /dev/dsp* after upgrade to 10.10

[calraith]

I run Mythbuntu. Relevant to this thread, I have the following hardware:

• An Nforce4 onboard sound card
• A pcHDTV HD5500 ATSC/NTSC/ClearQAM tuner
• A Pinnacle PCTV HD card, also tunes ATSC/NTSC/ClearQAM

Sound from the PC goes through an optical cable to a receiver for 5.1 digital / DTS audio. That's working smashingly. The digital portions of both the pcHDTV and Pinnacle cards play in realtime and record equally well. Huzzah! Additionally, the analog video capture works -- the /dev/vbi0 and vbi1 devices are there.

It's the analog audio capture with which I'm having problems. With Ubuntu 10.04 and earlier the analog v4l devices were accompanied by /dev/dsp#. Now they're gone. Where'd they go?

As a side note, I know ALSA sees my video capture audio devices, as alsamixer lets me choose among the three cards -- one NVidia (set as default), and two Connexant CX8801 devices. Everything's unmuted, set to a high volume, and capture enabled.

I look in /dev/snd and I see a bunch of bs I don't recognize, nor does it seem to have very intuitive naming. Just for giggles, in the Myth backend setup, I went ahead and manually set the non-existent /dev/dsp0 as the audio capture device for the pcHDTV card. Then I methodically did a ln -s /dev/snd/controlC0 /dev/dsp0, replacing controlC0 with each file in /dev/snd in turn and turning on live analog TV through the pcHDTV. No permutation worked.

So then I did cat /proc/asound/devices, with the following results:

  2:        : timer
  3:        : sequencer
  4: [ 0- 2]: digital audio capture
  5: [ 0- 1]: digital audio playback
  6: [ 0- 1]: digital audio capture
  7: [ 0- 0]: digital audio playback
  8: [ 0- 0]: digital audio capture
  9: [ 0- 0]: hardware dependent
 10: [ 0]   : control
 11: [ 1- 0]: digital audio capture
 12: [ 1]   : control
 13: [ 2- 0]: digital audio capture
 14: [ 2]   : control

I'm guessing that lines 11 and 13 refer to my pcHDTV and Pinnacle cards. With that in mind, in Myth backend setup I replaced the audio capture setting with ALSA:hw:1,0 and 2,0 respectively. That didn't help either.

Is there any way without having to go through recompiling the kernel to restore /dev/dsp functionality? If not, then how can I tell what devices are my analog audio capture devices so I can point Myth backend setup to the correct devices? What's the appropriate syntax?

[moosehadley]

It was removed to solve bugs, inadvertently creating a bug...

See https://bugs.launchpad.net/bugs/579300.

[calraith]

It was removed to solve bugs, inadvertently creating a bug...

See https://bugs.launchpad.net/bugs/579300.

Yep. Been there. It seems they're relabeling it as a feature, though. No moar /dev/dsp evar. It's the end of an era. So long, OSS. Ye shall be sorely missed.

Unless I can figure out what the crap I'm missing to recreate /dev/dsp by compiling my own kernel. I'm in the middle of compiling linux-image-2.6.35.22-fail to commemorate this situation.

Then I'm never freakin' upgrading my kernel until I am convinced of the following:

1. Pulseaudio must support 5.1 channel output through s/pdif on my Nforce 4.
2. Mythbackend must know how to talk to pulse, and documentation / howtos are everywhere explaining the proper syntax to replace "/dev/dsp" for the hardware location, or Mythbackend learns how to auto detect Pulseaudio.

... Or until I give up analog cable and go pure digital. You know, whichever comes first.

[calraith]

I now have my /dev/dsp devices back. I followed these directions for compiling my own kernel the Debian way. (On the "fakeroot make-kpkg –initrd –append-to-version=-custom kernel_image kernel_headers" line, use double-dashes for the switches though. --initrd and --append-to-version.) I enabled all the OSS stuff as modules, compiled, installed, dkms successfully and automatically compiled lirc and Nvidia stuff against my newly installed kernel headers, I rebooted, and now life is all sunshine and daisies again.

Attached to this comment is a copy of my kernel config file. If you wish to do the same as I have and compile your own kernel, download and gunzip this attachment, move it to /usr/src/linux/.config, load it as an alternate configuration when you make menuconfig, and tweak as necessary. You might need to go to "Processor type and features" --> "Processor family" and change if appropriate. The current setting in that config is for "Generic-X86-64."

So as it is now, mythfrontend uses ALSA (not Pulse) to output sound, so I get AC3 / Dolby and DTS 5.1 surround via digital coaxial or optical; mythbackend uses OSS (huzzah!) to hear the analog bits of my tuner cards; and if you listen closely you can hear motherfreaking angels sing.

And I'm never upgrading my kernel until Pulse better understands my hardware and Myth more seamlessly supports Pulse -- or until I get digital-only cable, whichever comes first.

Update: I modified my .config to disable the streamzap kernel module. lirc provides its own anyway, and the one in the kernel conflicts with the one in lirc. Disabling streamzap in the kernel (perhaps counterintuitively?) fixes broken Streamzap remote control functionality.

[sceo]

@Calraith, "your anguish sustains me."

Truly, I appreciate your situation; I have a pcHDTV-5500 where the sound stopped working since upgrading to Maverick. Is there anything else short of recompiling a kernel that is something easier to do?

If not, I'm formatting, accepting the loss of all of my recorded programs, and going back to Lucid LTS.

[calraith]

@Calraith, "your anguish sustains me."

Truly, I appreciate your situation; I have a pcHDTV-5500 where the sound stopped working since upgrading to Maverick. Is there anything else short of recompiling a kernel that is something easier to do?

If not, I'm formatting, accepting the loss of all of my recorded programs, and going back to Lucid LTS.

Nope. ALSA OSS emulation is required for /dev/dsp but is disabled in the kernel. But I wonder whether the new kernels with ALSA OSS emulation turned off are going to filter down to Lucid anyway. Compiling your own kernel is pretty painless, especially if you use my .config I attached above. If I were you, I'd give it a shot before formatting. If you end up formatting anyway, you really won't have lost anything by trying.

[sceo]

OK, I think I was just fearing the unknown. But as I realize I don't really want to copy gigs of my music and pictures off to somewhere else to format, I think you're thinking is quite correct. If it doesn't go right, I still have the option to format. So I will follow the directions and report back. Thanks for the vote of confidence.

[sceo]

Yeah, seemed to work like a charm, actually. For those of you also curious to do this, like us with pcHDTV-5500's, the only part I got hung up on was that even with calraith's config file, you'll still need to run the "menuconfig" part, you just won't have to make any edits. Just immediately exit the program.

[calraith]

For what it's worth, I've also been having trouble with my streamzap remote. (Technically it's a Logitech Harmony impersonating a streamzap, but I digress.) From what I gather, there exist both a kernel streamzap module as well as a module compiled by the lirc installation (sort of the same way installing the Nvidia driver introduces new kernel modules via dkms). Apparently the two different flavors of streamzap modules conflict. Doing "rmmod streamzap" seems to sort it out, whereas blacklisting streamzap in /etc/modprobe.d didn't.

I say all that to say this. I'mma recompile my kernel again and try disabling the streamzap module from within menuconfig. If that fixes my remote, I'll update the .config attachment above. At the moment I'm re-downloading linux-source.2.6.35.

I know there are easier ways to unload the streamzap module -- adding "rmmod streamzap" to /etc/rc.local, for example. But I'm weird this way. If by updating the attached .config above I can help people sort out not only their /dev/dsp issues but also a malfunctioning remote control, then gee whiz! It'll sure be swell!

[sceo]

For what it's worth, I've also been having trouble with my streamzap remote.

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!