The simplest way is to connect aplay
and arecord
by a pipe. There's no arecord -L
information for PCM sources, but assuming it looks similar to the PCM sinks:
arecord -t au -r 44100 -D front:CARD=Intel,DEV=0 | aplay -t au -D front:CARD=Intel,DEV=0
There's a noticable delay until the output is played, because a pipe isn't intended for real-time audio processing.
The -t au
options select the Sun Audio format. This is important, because e.g. the WAV format contains a header with the length of the file, so it can't be used across a pipe.
The default rate for arecord
is 8000 samples/s, which is usually not what you want, so the -r
option is also important.
The PCM sources and sinks may not support some combinations of rates/format/channels, so you either may have to pick valid combinations for your hardware using more options, or use plughw
instead of front
. For more modern ALSA installations, plughw
entries are automatically generated, and they put a plug
plugin in front of the real hardware to do format conversion. If your ALSA doesn't generate those automatically, you have to add them manually to your .asoundrc
.
There are other ways to do it, for example with a chain of various ALSA plugins, if you want to have this feature permanently. It's not necessary for the hardware to be able to route audio directly.
Interesting question, a long time ago I was thinking about simple recording
of digital audio and video, possible via some virtual audio and video
drivers, but never got there.
I used your configuration file and had exactly same problem as you
described. (I removed OSS compatibility drivers from ALSA to be sure, tested different
kernels - did not seem to matter, and used Debian Wheezy)
$ alsaplayer -d front audio.mp3
$ mplayer -vo null -ao alsa:device=front video.mp4
AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
$ mplayer -ao alsa:device=front audio.mp3
AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
the above commands all play OK to speakers
$ arecord -f cd -D loop | aplay -f cd -D front
Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
now recording from loop and playing to front
$ alsaplayer audio.mp3
$ alsaplayer -d loop audio.mp3
$ mplayer -vo null video.mp4
$ mplayer -vo null -ao alsa:device=loop video.mp4
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
$ mplayer -ao alsa:device=loop audio.mp3
AO: [alsa] 48000Hz 2ch floatle (4 bytes per sample)
all sending audio to loop and playing to speakers OK
$ mplayer audio.mp3
AO: [alsa] 48000Hz 2ch floatle (4 bytes per sample)
but here the sound is broken - very distorted!!! Just playing to default device. Playback specified via loop worked!
After trying various changes I tested this modification of asound.conf
pcm.!default {
type plug
slave.pcm "loopout"
}
It solved the problem! When the default device is loopout it works.
Trying arecord -f cd -D loopin | aplay -f cd -D front
did not have any
effect. Not sure how the loop works but this was able to capture the audio.
Or a bug in ALSA? Are you using Debian? Does it work for you?
Notes to other suggestions to solve the problem:
To dump the network stream: I assume if the application does not want you to
save data, the transfer would be encrypted (https ???). In case the player does
not check the server certificate how do you capture the data? What is your favorite
quick & easy method how to become man in the middle and capture the stream?
Pulseaudio: How do I get it running on Debian Wheezy? The Wiki says it just works.
It did not.
/etc/init.d/pulseaudio start
[warn] PulseAudio configured for per-user sessions ... (warning).
How do I troubleshoot what is going on? (Tools, diag?)
Jack: I did not find any simple instructions how to install Jack.
It seems quite complex. Does it assume Pulseaudio running?
The documentation is confusing. Do you have a link for a nice quickstart
(how to install and test to make sure it is working?)
Do you assume that most audio applications (like Fios Voicemail Java player)
will be able to play to Pulseaudio or Jack and not send audio to ALSA?
Best Answer
The
ipc_key
is used for communication between the programs that share the same device. This means that you have to use different values for different hardware devices, but that all virtual devices that access the same hardware device (i.e., the same slaveusb_audio_1
) must use the same ID.