Solved Mplayer playlist over SSH.

E

Ellicia

I've been having troubles running my playlist with mplayer over ssh. This used to work without any issues for me with the following:

ssh -i .ssh/user_key.id_rsa user@host "mplayer -shuffle -playlist /path/to/playlist.txt -af resample=44100,channels=2,format=s16le -ao pcm:file=/dev/stdout -quiet -really-quiet" | aplay -t raw -c 2 -f S16_LE -r 44100

I'm not really sure when this changed, but I have upgraded the server and my desktop that it plays from several times since I last used it for music. What happens is it just plays back static on my desktop. I've managed to get bits of the music by removing the -quiet -really-quiet flags, but I get a second of music followed by a second of static and it just repeats like that.

Can anybody offer suggestions on what else I might be able to change in order to get the stream to move without any static? I'm at a bit of a loss at this point and any suggestions would be greatly appreciated.
 
It appears that mplayer outputs something to stdout that isn't PCM data. Maybe some status messages. Even if it outputs just one additional byte (or an odd number of bytes), then all the rest of the PCM data is shifted by one byte, i.e. swapping high and low bytes of the PCM data, resulting in all static.

Have you tried -msglevel all=-1, with or without -quiet -really-quiet?
 
What is aplay? Isn't it an "alsa player"? Everything perfectly works here when piped to play (which is actually audio/sox).
Code: 
... | play -r 44100 -b 16 -c2 /dev/stdin
 
The OP could try using a different player on the linux side like cvlc the command line interface to vlc,
ffplay, mplayer or mpv

I have used aplay on linux before and seem to remember having a few issues thats why i would use something like ffplay or mpv on linux

I suggested catting the text file over ssh as there are fewer working parts to break,
its a shorter command to type and the end result is the same but as you saw the OP may have a reason to stream the audio overs ssh rather than the playlist
 
Another option is using ffmpeg to multicast the audio and then use vlc to open the stream,
the advantage is you can stream to all the devices on your network at once

Create a file "mylist.txt" with all the files you want to have concatenated

Bash: 
# this is a comment
file '/path/to/file1'
file '/path/to/file2'
file '/path/to/file3'

use ffmpeg to concat the mylist.txt file and multicast stream the audio,
and set the audio bit rate to 384k

Bash: 
ffmpeg -f concat -i mylist.txt \
-c:a libfdk_aac -b:a 384k \
-f mpegts udp://239.253.253.4:1234?pkt_size=1316

Open the stream with vlc

Bash: 
vlc -vvv udp://@239.253.253.4:1234

or use the command line version of vlc cvlc

Bash: 
cvlc -vvv udp://@239.253.253.4:1234

This would work on the lan but not over ssh,
so wouldnt be suitable for streaming over the internet but would work with 2 computers on the same lan
 
NapoleonWils0n said:
The OP could try using a different player on the linux side
Click to expand...
He didn't mention Linux at all. He probably uses FreeBSD on both sides.
I suggested catting the text file over ssh as there are fewer working parts to break,
its a shorter command to type and the end result is the same but as you saw the OP may have a reason to stream the audio overs ssh rather than the playlist
Click to expand...
Yes, I also assume he has a reason to do it like that. His playlist probably contains mp3 files on the same remote host, so transferring just the playlist wouldn't work, because the mp3 files cannot be played directly on the local host. There would be several other ways to solve the problem, of course, but just transfering the decoded PCM stream is indeed the simplest solution.
 
olli@ said:
He didn't mention Linux at all. He probably uses FreeBSD on both sides.
Click to expand...

aplay is a command line player for alsa,
thats why i assumed linux but i may be wrong

I used to use the logitech media server which worked really well and synchronized playback,
so you could have multi room audio, but im not sure if thats an option on Freebsd
 
olli@ said:
It appears that mplayer outputs something to stdout that isn't PCM data. Maybe some status messages. Even if it outputs just one additional byte (or an odd number of bytes), then all the rest of the PCM data is shifted by one byte, i.e. swapping high and low bytes of the PCM data, resulting in all static.

Have you tried -msglevel all=-1, with or without -quiet -really-quiet?
Click to expand...

Thank you for the insight on this. I went ahead and tried adding the the flag you mentioned (with and without the quiet flags) and it just produced static.
 
aragats said:
What is aplay? Isn't it an "alsa player"? Everything perfectly works here when piped to play (which is actually audio/sox).
Code: 
... | play -r 44100 -b 16 -c2 /dev/stdin
Click to expand...

I do have play on both systems. When piping the mplayer output to play -r 44100 -b 16 -c2 /dev/stdin it produces the following error.

Code: 
play FAIL formats: can't determine type of file `/dev/stdin'

Which I find rather odd that that's coming up.
 
Try using sox directly (play is an alias to certain sox options), it works here:
Code: 
... | sox -t raw -r 44100 -b16 -c2 -L -e signed-integer /dev/stdin -d
 
aragats said:
Try using sox directly (play is an alias to certain sox options), it works here:
Code: 
... | sox -t raw -r 44100 -b16 -c2 -L -e signed-integer /dev/stdin -d
Click to expand...

Thank you for posting the additional flags as I am not familiar with sox and play. Was able to run it without any errors.

This puts me in the same spot I was with aplay where I'm receiving a fragment of music, followed by static -> music -> static.

Ran the command on the server itself as well and it is producing the same behavior.

The output looks fine from the desktop:
Code: 
[23:16][redacted@local ~]$ ssh -i .ssh/redacted\@remote.com.id_rsa redacted@remote"mplayer -shuffle -playlist /home/redacted/Music/pop.playlist -af resample=44100:0:1,channels=2,format=s16le -ao pcm:file=/dev/stdout  " | play -t raw -r 44100 -b16 -c2 -L -e signed-integer /dev/stdin

/dev/stdin:

  Encoding: Signed PCM
  Channels: 2 @ 16-bit
Samplerate: 44100Hz
Replaygain: off
  Duration: unknown

In:0.00% 00:00:00.00 [00:00:00.00] Out:0     [      |      ]        Clip:0    MOTD stuff...
Enter passphrase for key '.ssh/redacted@remote.id_rsa':
In:0.00% 00:00:10.59 [00:00:00.00] Out:467k  [   ===|===-  ] Hd:0.0 Clip:0    ^C
Aborted.

I did want to clarify that both systems are running FreeBSD as I wasn't clear about that in my first post.
 
Ellicia said:
Can anybody offer suggestions on what else I might be able to change in order to get the stream to move without any static?
Click to expand...

Something like mplayer -shuffle -playlist /path/to/playlist.txt -af resample=44100,channels=2,format=s16le -ao pcm:file=/dev/stdout -quiet -really-quiet | hexdump -v -C | head -n 20

As olli@ suggested earlier in this thread it must be some status message or a similar thing.
 
shkhln said:
Something like mplayer -shuffle -playlist /path/to/playlist.txt -af resample=44100,channels=2,format=s16le -ao pcm:file=/dev/stdout -quiet -really-quiet | hexdump -v -C | head -n 20

As olli@ suggested earlier in this thread it must be some status message or a similar thing.
Click to expand...

I really appreciate the reply. This has shed light on what's going on here.
Code: 
00000010  5c 52 49 46 46 24 f0 ff  7f 57 41 56 45 66 6d 74  |\RIFF$...WAVEfmt|
00000020  20 10 00 00 00 01 00 02  00 00 7d 00 00 00 f4 01  | .........}.....|
00000030  00 04 00 10 00 64 61 74  61 00 f0 ff 7f 00 00 00  |.....data.......|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Yes, there are only 19 lines here. I retracted the very first line as it gives away my server hostname and that is somehow being sent over the stream, followed by the additional 3 lines.

I'm guessing when working correctly it should only be sending along the lines of data after those strings. Please correct me if that is not right.

Now, I have no idea why it is putting out that additional information nor how to prevent it.
 
Ok. After running ssh with very verbose flags I was able to see what was going on here.

Code: 
debug3: Executing /bin/bash -c "~/.ssh_hostname redacted"

That file contained the following:
Code: 
#!/bin/bash
echo -ne "\033k$1\033\\"

This is a file I created awhile back to give me the hostname of the server I was logged into via ssh. Since I use screen when frequently working with multiple servers and it's very helpful to know what server I'm working on when switching back and forth.

Moving this file out of the way I was able to get this running again. I wanted to thank everybody for all of their input on this.
 
You must log in or register to reply here.
Back
Top