Solved Mplayer playlist over SSH.

Ellicia

New Member


Messages: 10

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.
 

olli@

Active Member
Developer

Reaction score: 221
Messages: 246

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?
 

aragats

Daemon

Reaction score: 434
Messages: 1,057

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
 

NapoleonWils0n

Active Member

Reaction score: 34
Messages: 113

Why not just pipe the text file over ssh using cat,
something like this

Code:
mplayer <(ssh yourserver.com cat /path/to/textfile.txt)
 

aragats

Daemon

Reaction score: 434
Messages: 1,057

Why not just pipe the text file over ssh
The OP pipes audio stream, not text. I checked the same command with two FreeBSD computers and sox(1), and it works.
If the OP uses Linux in one of the machines, it could be ALSA's issue, not mplayer's.
 

NapoleonWils0n

Active Member

Reaction score: 34
Messages: 113

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
 

NapoleonWils0n

Active Member

Reaction score: 34
Messages: 113

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
 

olli@

Active Member
Developer

Reaction score: 221
Messages: 246

The OP could try using a different player on the linux side
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
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.
 

NapoleonWils0n

Active Member

Reaction score: 34
Messages: 113

He didn't mention Linux at all. He probably uses FreeBSD on both sides.
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
 
OP
OP
E

Ellicia

New Member


Messages: 10

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?
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.
 
OP
OP
E

Ellicia

New Member


Messages: 10

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
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.
 

aragats

Daemon

Reaction score: 434
Messages: 1,057

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
 
OP
OP
E

Ellicia

New Member


Messages: 10

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
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.
 

shkhln

Well-Known Member

Reaction score: 133
Messages: 380

Can anybody offer suggestions on what else I might be able to change in order to get the stream to move without any static?
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.
 
OP
OP
E

Ellicia

New Member


Messages: 10

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.
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.
 
OP
OP
E

Ellicia

New Member


Messages: 10

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.
 
Top