I'm not sure if people here would be willing to help me with this crazy Frankenstein problem I've created or not. I'm attempting to pipe sound output from a Qemu system running Slackware-11.0 (yep-- *that* Slackware-11.0). And, I try to load the included ALSA loopback device from Slackware-11.0's alsa-driver package (modprobe snd-aloop). And, I get *this* crazy crap:

Warning: /lib/modules/2.4.33.3/kernel/sound/drivers/snd-aloop.o.gz symbol for parameter pcm_devs not found
Module snd-aloop loaded, with warnings

And, I check aplay -l. And, it shows the expected devices:

**** List of PLAYBACK Hardware Devices ****
card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7

And so, that's cool. So, I try piping the listening device (the playing device "hw:0,0,0" will be the system default and the listening device that repeats its output will be "hw:0,1,0" for those not familiar with ALSA loopback devices) to a port (port 9598 is forwarded to host port 10622 via Qemu Slirp, if that's relevant):

arecord -D "hw:0,1,0" -f S16_LE -c 2 -t raw -r 44100 | nc -l -p 9598

And then, I try playing a file using the ol' mpg321:

mpg321 a_statue_of_the_king.mp3

And-- the system completely freezes. I can switch to a new terminal and log in. But if I try to acquire a process ID (ps -fu user | grep mpg321) or simply kill any mpg321 process (killall mp321), then *that* terminal locks up (lol). And so, I'm kind of unsure where I would like to go from here. I've already got a similar setup working perfectly fine using Slackware-12.0 on top of Qemu. Since Slackware-12.0 comes with a 2.6 kernel, it has no alsa-driver package. And (coincidentally), it has no pre-built ALSA loopback module (either Volkerding accidentally did not build one or the kernel simply did not have the feature, yet). So, I compiled alsa-driver-1.0.14 (and prompted configure to build the loopback device driver: "--with-cards=loopback"). And, I can modprobe snd-aloop. And, everything works perfectly fine.

So, I've tried rebuilding Slackware-11.0's alsa-driver package (using its included source and SlackBuild). And, I added the same configure option to the SlackBuild (why not, right?) And, everything just builds. But I mean, I get the same message when I modprobe snd-aloop. And, the only really strange thing I see is a configure message "*** NO PREDEFINED KERNEL COMPILER IS DETECTED ***" when I configure the package build system. This is like-- the only piece of viable information I have to go on. And (honestly), I don't see why this would cause a problem (it seems to me that the configure script is simply trying to verify that the kernel wasn't compiled with GCC version 2 and-- that's the only purpose for this test). And, I can't seem to find any other posts where people experienced this problem compiling ALSA packages and actually got the configure message to go away (or that this helped).

I also built (successfully) Slackware-12.0's ALSA packages for Slackware-11.0. And then, I built alsa-driver-1.0.14. And, I get the same pcm_devs warning when I modprobe *its* snd-aloop device as well. So, I really don't know what to do from here. I'm not sure what level of interest other Linux Questions users have in repairing Slackware-11.0. But, I would appreciate any insights people are willing to share with me regarding its ALSA loopback module. Um, I would *really* like to understand the "symbol for parameter pcm_devs not found" message itself (so-- maybe there's a pcm_devs feature missing from the kernel and it needs to be rebuilt with this feature enabled??)

Can you confirm that neither of those Frankenstein boxes ever go online? Otherwise, I imagine many here might not be inclined to assist.

One other thing: Why not update, even just to slackware-12.0?

Slackware 12 and 13.37 have reached end of life; they're no longer supported. Would you be able to run Slackware 14? If the unit is connected to the Internet security patches are important. Just my opinion.

I'm kind of confused as to what you are ultimately trying to do: are you running an undisclosed host (possibly modern Linux) with an old Slackware 11 Qemu guest or are you trying to run a Slackware 11 host bare metal with an undisclosed Qemu guest? You have no real sound card (listed in aplay -l). Even older systems should be able to use AC97, and pipe to Alsa instead of PA if you wish.

Note that Qemu syntax has radically shifted over the years. This assumes modern Qemu...and that you're running a Slackware 11 guest. I fail to see the importance of the loop module; you just want sound from the guest to the host, correct?

Well, the assumption that this mysterious "pcm_devs missing symbol" modprobe message was the problem was my biggest mistake. Yes, I have discovered what this message means (no thanks to anybody here). And if you would really like to get rid of it, simply compile the alsa-driver snd-aloop module with a non-static pcm_devs() function. If you read about the "nm" command, you'll discover that there are exported kernel symbols (for example, you might wanna implement a module which exports symbols using the EXPORT_MODULE() macro), non-exported kernel symbols, etc. And so, you can change drivers/aloop-kernel.c's pcm_devs() declaration from this:

static int pcm_devs[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 1};

to this:

int pcm_devs[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 1};

And, you can try building again (./configure; make; make install; echo "ho-hum"). And yeah, you'll get rid of this obscure message that modprobe (apparently) writes on stderr when you've got a module with an active "private symbol" on a 2.4 kernel. Umm-- this did not fix *my* problem (lol). Just to reiterate (I can see from people's messages here that maybe a few people were kinda confused about my actual problem), the problem I was having is that when I ran mpg321 (or even something innocuous like piping /dev/urandom to aplay), the process would get stuck (the specific process-- not necessarily the entire system). And, I could open other terminals and still do some things. But just checking for the process (like: "ps -fu user | grep mpg321") would cause *that* terminal to freeze. And-- removing the missing "pcm_devs" symbol message from the snd-aloop module? Nope, that didn't fix the problem.

So, I tried reinstalling the Slackware-12.0 ALSA packages I compiled previously. And, I tried my mpg321 setup, again. I simply ignored that (apparently harmless) "pcm_devs" message and completed the setup:

arecord -D "hw:0,1,0" -c 2 -f S16_LE -r 44100 -t raw | nc -l -p 9598

And, I picked up nc's data on port 10622 using a client system (again-- Qemu Slirp is forwarding 9598 to 10622):

nc 10.0.0.50 10622 | aplay -c 2 -f S16_LE -r 44100 -t raw

And, that all worked fine (as before). And then, I tried the cat's meow (actually writing audio data):

mpg321 a_statue_of_the_king.mp3

And, it worked perfectly fine. So, that's what I have to say about red-herrings. And, I hope this information might help a developer setup an ALSA loopback device using Slackware-11.0 on top of Qemu like *I* did. Simply compile Slackware-12.0's ALSA packages using Slackware-11.0. And then, compile alsa-driver-1.0.14 using Slackware-11.0's alsa-driver SlackBuild script (don't forget to add the configure option "--with-cards=loopback" to the SlackBuild). You're welcome.

2 members found this post helpful.

Hey username_11011! It does seem your report on the loopback to nc might be helpful. I was trying to run a special setup of pipewire on Slackware 15 in qemu, and I was getting a similar weird situation that the process using sound would just get stuck with no indication why. I was not using loopback there. But perhaps there is something odd about the kernel under qemu emulation and creating a loopback device may be the best way to go. I was also testing various old versions of slackware, including 11 and 12 to remind me on some things that were once were. I decided to stop running qemu and use live hardware due to emulation concerns (including audio and other things not just that). It's not great having a bunch of machines, and I'm running low on hard drives already in my tests.

I am remembering that I used some kind of loopback recording on OSS. This would have been about 20 years ago. It might have been a wrapper to a command, or a device driver creating a device node to point to. So I think there may be another option on old slackware to get sound out of qemu.

Thank you.

My Slackware-11.0 VM has working sound, using an emulated AC97 sound card. I can't remember what I did to get it working, because it was set up some time ago.

I'll see if I can set up a new VM, and will report back here.

Further to my previous post: 'modprobe snd-aloop' gives me the same result as OP in post #1.

Edit - Just ran a clean install of Slackware 11.0 in a VirtualBox VM (hosted by Slackware 15.0) and found that sound worked for me out of the box, using an emulated AC97 sound chip as above.

lol-- didn't realize people continued poking at this old scab a bit. Yeah, I'd say that is a functional problem there between Linux 2.4 and Slackware-11.0's included ALSA drivers package. The newer SlackBuilds for Slackware-12.0 (well-- I had to compile ALSA drivers on my own because Slackware-12.0 doesn't come with that package since they're built-in to Slackware-12.0's 2.6 kernel) fixed my loopback needs no problem. Sure-- I'm fully aware a person can launch a Qemu system with an attached audio device (such as Qemu's AC'97 emulated device). I believe I started with that (at one point in time). I got that working perfectly fine on top of KVM (running on a 64-bit x86 with hardware virtualization).

For my next trick (lol), I proceeded by booting the same system (that would've been Slackware-12.0 for this test) on top of Qemu's tiny code generator (TCG) hosted by a Raspberry Pi running Luca's bonslack-15.0-aarch64. I don't know what your knowledge is about Qemu. I can assure you, mine is quite extensive (don't get me stahhhted). But, I already knew going in that Pulseaudio compiled for Slackware-11.0 (even using Linux 2.4) on top of tcg is a no-go (totally useless for producing audio output-- nothing but fragments of trash every second or so). And (I quickly found out), AC'97 is the same story (on top of tcg, mind you). So, I looked into ALSA a bit. And, I discovered I could send the raw audio data (totally unprocessed by any Qemu audio devices) to a port by recording a loopback device with built-in Slackware-11.0 software (like, uh-- arecord). And then, a host could do the processing.

According to Qemu's online documentation, the bottleneck of producing audio is related to the crude methods Qemu uses to process it (un-thoughtful C code pretending to be hardware and whatnot). Combine that with the use of its tiny code generator, and-- you come up with: "Perhaps the host should do the audio processing, instead". I mean-- if you wanna produce audio with a Qemu tcg system (*I'm* certainly getting some good use out of it, lol). So I tried that out, and it works perfectly fine. So, that was the method I decided to try for Slackware-11.0. Glad I was able to get that working. And, I hope my solution can help other LinuxQuestions visitors in the future.

Do you know how to do loopback recording on a windows client and pipe to a port on a linux host? Some of my test vms for a few versions of slackware, the audio was nearly perfect with qemu emulated device, and other versions not as much. On windows, the audio is pretty atrocious with an emulated device, so another option would be very nice.

I think the virtio drivers in the most recent slackware, are pretty good for i/o, so that may be why audio is good. For some reason, i/o on windows never seems to be any good, even with the virtio drivers.

Well first of all, kinda rude asking me this (on *my* own feed that is already solved, lol). Just sayin'. Secondly, well-- what you truly desire (in my opinion) is some deeper understanding about operating systems and kernels. A real operating system (like Slackware and other GNU/Linux systems) has a kernel that implements proper file descriptors. And, that is exactly what ALSA's loopback device is. And so, what you're really wanting is a file descriptor like that on a Windows system. And then, you wanna just-- install MinGW or Cygwin (which promise the possibility of providing arecord and nc for a Windows system).

On the surface, it sounds pretty simple. Unfortunately-- we're not talking about an operating system. We're talking about a piece of trash that is (really) a DOS kernel with a built-in API (that is barely functional). And, it is *not* an operating system (and, I refuse to call it that!) And it simply doesn't implement file descriptors, properly. And so-- you're stuck looking into Cygwin (which I know very little about). Maybe it has an ALSA implementation (with loopback devices) that is designed to overcome Windows' pitiful functionality. Other than that-- well, maybe VLC (compiled for Windows) can be your friend. And, maybe *it* has a feature that can pipe unprocessed Windows audio to a port. I'm afraid that is the best I can do for you.