You are not logged in.

#1 2016-02-19 18:01:58

miomio
Member
Registered: 2016-01-17
Posts: 167

ffmpeg to stream default audio device over network

My laptop speakers are dead (second hand laptop, took a gamble). So I'm trying to stream the default device over the network so I can pick up up with VLC running on my phone. So far I've gotten the following:

ffmpeg -f alsa -i hw:0 -c:a libmp3lame -ar 11025 -f rtp rtp://192.168.0.7:8099

This command is streaming something because I can see the data via sysdig with:

sysdig -A -c echo_fds proc.name=ffmpeg and fd.type=ipv4

However, I cannot see an open socket on the machine:

ss -plant | grep 8099

It's quite a technical topic for me. I'm simply just after opening my default playback device, tapping the signals sent to the dead speakers, and streaming it over the network. Anybody able to point help?

The resources I'm using are:

https://sonnati.wordpress.com/2011/08/3 … 3-part-iv/
https://trac.ffmpeg.org/wiki/StreamingG … tstreaming
https://trac.ffmpeg.org/wiki/Capture/ALSA
https://ffmpeg.org/ffmpeg-devices.html#alsa

Offline

#2 2016-02-21 05:08:37

pigiron
Member
From: USA
Registered: 2009-07-14
Posts: 150

Re: ffmpeg to stream default audio device over network

Reading your posts (both of them), I'm left wondering if you might have embarked on a insanely complex quest where you've only begun to scratch the surface.

Firstly, if I'm reading the man page for ffmpeg correctly, the -i hw,0 paramater shows that you want to stream the input from the "default" ALSA device. So that means the audio that's headed for the "first" device coming into the system running ffmpeg (like from a TV tuner or microphone, for example). ALSA calls this the "default" Capture device. Perhaps that's exactly what you want to do, but you don't mention it. Maybe you've created an ALSA loopback device to send any audio destined for the ALSA "Play" device to loop back to the "Capture" device, but again, you don't mention it. Also, if you're running Pulseaudio, you might need to first release it from it's clutches since you may be asking for exclusive access... but again, no mention if you're using Pulseaudio.

As for the question of if there any packets being sent from port 8099 on the ffmpeg system, running the tcpdump utility on that box will leave no doubt if you know how to decipher the output.

One other thing I wonder about is the VLC running on your phone. According to the VLC docs, it uses the LiveMedia libraries when it's a RTP client. If I remember correctly, you can build VLC without this support (but I'm not postive). Perhaps if you replace ffmpeg with VLC as the streaming source your luck may change as I don't *think* that uses the RTP protocol.

All the above might seem somewhat negative, but by no means do I think that you should give up. I was on a quest somewhat similar to yours (wirelessly squirting 16/44.1). It took me a long time to jump over obstacles followed by more speed bumps, but eventually there was decent success. So keep digging.

On the other hand, I've got a company laptop that's borked like yours (no speaker output). After a deep dive (including HDA Analyzer and jacksense) I took the lazy way out and bought a USB audio dongle.

Last edited by pigiron (2016-02-21 05:19:36)

Offline

#3 2016-03-05 15:07:40

miomio
Member
Registered: 2016-01-17
Posts: 167

Re: ffmpeg to stream default audio device over network

pigiron wrote:

...you might have embarked on a insanely complex quest where you've only begun to scratch the surface.

Correct.

In any case, I've dropped using ffmpeg now. It was a headache.

pigiron wrote:

Perhaps if you replace ffmpeg with VLC as the streaming source your luck may change...

Well, I installed PulseAudio and followed the Freedesktop documentation to transcode the raw PulseAudio RTP stream into MP3 with VLC out over the network, then using VLC on my phone, open up the stream. However, the problem I'm having now is that despite having followed this documentation to the dot I am ironically no better off than when I was searching for the answer with ffmpeg: https://www.freedesktop.org/wiki/Softwa … /#index6h2 I am closer.

So if you take a look at the above link you'll see that I have uncommented the following in `/etc/pulse/default.pa`, as described:

### Load the RTP sender module (also configured via paprefs, see above)
load-module module-null-sink sink_name=rtp format=s16be channels=2 rate=44100 sink_properties="device.description='RTP Multicast Sink'"
load-module module-rtp-send source=rtp.monitor destination_ip=127.0.0.1 port=47777 loop=1

The only difference here is that in the documentation (link above) there is no `destination_ip`, only `destination`. I believe the RTP how-to doc to have been written prior to PulseAudio 4.0 since the module page describes the switch as being `destination_ip` and not `destination`: https://www.freedesktop.org/wiki/Softwa … #index38h3

Anyway, after saving the `default.pa` config file and restarting pulseaudio I then begin transcoding with cVLC to stream the RTP stream as MP3 for lower bandwidth consumption, as described in the Freedesktop doc linked above:

cvlc rtp://@127.0.0.1:47777 ":sout=#transcode{acodec=mp3,ab=256,channels=2}:duplicate{dst=rtp{dst=225.0.0.1,mux=ts,port=47778}}"

After this, I can confirm UDP sockets for pulseaudio on port 47777 and cVLC on port 47778 (I have no idea why port 47779 was opened):

$ ss | grep 4777
udp    ESTAB      0      0      127.0.0.1:59568                127.0.0.1:47777                
udp    ESTAB      0      0      192.168.0.3:60226                225.0.0.1:47778                
udp    ESTAB      0      0      192.168.0.3:60227                225.0.0.1:47779

Sure enough there is a stream headed out to the multicast address on port 47778:

# tcpdump -n net 225.0.0.0/8 -c 10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:48:52.016950 IP 192.168.0.3.60226 > 225.0.0.1.47778: UDP, length 1328
14:48:52.017000 IP 192.168.0.3.60226 > 225.0.0.1.47778: UDP, length 1328
14:48:52.017009 IP 192.168.0.3.60226 > 225.0.0.1.47778: UDP, length 1328
14:48:52.017018 IP 192.168.0.3.60226 > 225.0.0.1.47778: UDP, length 1328
14:48:52.017028 IP 192.168.0.3.60226 > 225.0.0.1.47778: UDP, length 1328
14:48:52.017038 IP 192.168.0.3.60226 > 225.0.0.1.47778: UDP, length 1328
14:48:52.234093 IP 192.168.0.3.60226 > 225.0.0.1.47778: UDP, length 1328
14:48:52.234182 IP 192.168.0.3.60226 > 225.0.0.1.47778: UDP, length 1328
14:48:52.234219 IP 192.168.0.3.60226 > 225.0.0.1.47778: UDP, length 1328
14:48:52.234262 IP 192.168.0.3.60226 > 225.0.0.1.47778: UDP, length 1328
10 packets captured
12 packets received by filter
0 packets dropped by kernel

Now, from here I use my mobile phone with the VLC app to open the RTP stream with:

rtp://@225.0.0.1:47778 --rtp-caching=1000

(NOTE: switch `--rtp-caching=1000` is additional and I learned of it to reduce delay from here: https://forum.videolan.org/viewtopic.php?t=51322)

The result is low volume static noise coming out of my phone. No audio from the laptop despite firing up YouTube to make some noise.

Checking the `pactl` for sink and source info to confirm config I can see the following:

$ pactl list | grep -A2 'Source #' | grep 'Name: .*\.monitor$' | cut -d" " -f2
alsa_output.pci-0000_00_1b.0.analog-stereo.monitor
rtp.monitor
$ pactl list | grep -A2 'Sink #' | grep 'Name:'
	Name: alsa_output.pci-0000_00_1b.0.analog-stereo
	Name: rtp

I'm not too sure how loading these modules actually works since firstly the documentation for module-null-sink states "all data written to this sink is silently dropped" (https://www.freedesktop.org/wiki/Softwa … /#index3h3) and secondly the documentation for module-rtp-send states that this module "...reads audio data from an existing source and forwards it to the network encapsulated in RTP" (https://www.freedesktop.org/wiki/Softwa … #index38h3). So following this through then:

1. What am I doing opening a sink device to drop anything written to it? Additionally, what is being written to it?
2. what source device is feeding `module-rtp-send`?
3. Dafuq. Why is this difficult. And why is the documentation incorrect.

In simple terms I'm simply wanting to send audio coming from (presumably) `alsa_output.pci-0000_00_1b.0.analog-stereo.monitor` to loopback (again, presumably) with `module-rtp-send` where it is dealt with by that module and sent as a raw RTP stream to loopback where then I use cVLC to transcode the raw stream and send out over the network to a multicast address as MP3...

pigiron wrote:

On the other hand, I've got a company laptop that's borked like yours (no speaker output). After a deep dive (including HDA Analyzer and jacksense) I took the lazy way out and bought a USB audio dongle.

This is my home laptop and it would be nice to be able to get this working without extra hardware. Thanks for your feedback.

Last edited by miomio (2016-03-05 15:35:16)

Offline

Board footer

Powered by FluxBB