Arch Linux

tingdling

Member

Registered: 2017-07-16

Posts: 6

ALSA doesn't list created virtual devices through aplay -L

Hello,

I'm trying to set up virtual device which would be usable by some application.
I have a setup with ALSA-PulseAudio, with PAudio being the default output. However for certain applications I need direct access as Pulse creeps the hell out of my data...
The idea is to create plughw or hw equivalent using .asoundrc as follows

pcm.InterPlug {
   type plug
   slave {
      pcm "hw:1,0"
   }
}

Tesing the created device seems to be OK, as both of these command play the sample:

aplay -D hw:1,0 -sample.wav
aplay -D InterPlug -sample.wav

What does not work is aplay -L, that outputs only default devvices

[user@hostname ~]$ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
pulse
    PulseAudio Sound Server
default
    Default ALSA Output (currently PulseAudio Sound Server)
hdmi:CARD=HDMI,DEV=0
    HDA Intel HDMI, HDMI 0
    HDMI Audio Output
hdmi:CARD=HDMI,DEV=1
    HDA Intel HDMI, HDMI 1
    HDMI Audio Output
hdmi:CARD=HDMI,DEV=2
    HDA Intel HDMI, HDMI 2
    HDMI Audio Output
sysdefault:CARD=PCH
    HDA Intel PCH, ALC3232 Analog
    Default Audio Device
front:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    Front speakers
surround21:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    4.0 Surround output to Front and Rear speakers
surround41:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers

I tried to relocad using alsactl restore, restart the whole machine, searched everywhere but I can't find why this is happening.
The software I use seems to be using output of aplay -L to list available devices.. So I need the virtual device to be listed
Thanks for any help

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 21,627

Re: ALSA doesn't list created virtual devices through aplay -L

That virtual device, as it stands, will give you nothing that directly accessing hw:1,0 wouldn't give you anyway, if your application lists the pcms, simply use the front pcm which will be the functional equivalent to what you are trying to define.

However, we are deep into XY Problem territory here.

What is your problem? What does "creeps the hell out of my data" mean, which application is giving you issues and in what way do these issues represent themselves post terminal output of the affected application. There is a high likelihood that what you are trying to do here isn't the correct way to go about fixing whatever actual problem you are having.  So stop thinking about why aplay -L doesn't list your PCM and post information on what the real end goal is. Adding a custom PCM to aplay -L is a (potentially) wrong intermediate step. What is your end goal?

tingdling

Member

Registered: 2017-07-16

Posts: 6

Re: ALSA doesn't list created virtual devices through aplay -L

Hi, you are right, the front device seems to be an equivalent.

Now to sink into the XY problem a bit further

"Creeps the hell out of my data" means once passed though PulseAudio, the audio data are pretty much ready to go to the grave, rather then to an amplifier.. The distortion and format "corrections" are simply terrible. Its not like I would be chasing some tiny 0.001% of distortion, its audible for pretty much everybody.
I use jRiver MediaCenter to play the data and monitor what channel to the soundcard was opened by simply

cat /proc/asound/card1/pcm0p/sub0/hw_params

I have to believe the machine from that point, I'm not precise enough to hook up the probes on the USB and try to decode the data.. Even though it could be a nice exercise

So, to sum up my goals:
1) be able to play the data correctly - seems to be solved by using "front", thanks again for that
2) feed experimental virtual devices to jRiver (for further testing of what can be done by .asoundrc like channel remapping, etc.)