Picoreplayer directly play audio from usb/line-in

[DerTeufel]

For now I tried (still on my pc), modifying the "action" which is being perfomed when using WaveInput plugin.
Those changes are actually straight forward...
in '/opt/logitechmediaserver/cache/InstalledPlugins/Plugins/WaveInput' I modified 'custom-convert.conf'

this orignal line

[arecord] -d0 -c2 -f S16_LE -r 44100 -traw -D $FILE$

I replaced with

[arecord] -D plughw:1,0 -d 5 -f S16_LE -c1 -r44100 | [aplay] -D plughw:1,0

(input and output device just hardcoded).

In theory, this should be working now... but for me, neither the original cmd, nor the modified do work, when executed through the plugin page, but they do work, when executed from terminal.
I suspected this being some group related permissions issue and added both, 'logitechms' and 'squeezelite' to audio group, but didn't help

[bpa]

To debug what is happening with arecord or aplay, Redirect syserr ( something like 2>& /tmp/error.txt ).
You can also use tee between arecord and aplay to check if problem is input or output.

Better still in the custom-convert.conf execute a shell script containing the arecord aplay stuff. This way you can alter script without having to restart lms.

[DerTeufel]

To debug what is happening with arecord or aplay, Redirect syserr ( something like 2>& /tmp/error.txt ).
You can also use tee between arecord and aplay to check if problem is input or output.

Better still in the custom-convert.conf execute a shell script containing the arecord aplay stuff. This way you can alter script without having to restart lms.

The issue seems to be, when trying to pipe the audio by using/modifying your plugin, the output device already is being used by anything (your plugin?).

#!/bin/bash

exec 3>&1 4>&2
trap 'exec 2>&4 1>&3' 0 1 2 3
exec 1>/tmp/audio.log 2>&1

echo "starting arecord..."
/usr/bin/arecord -D plughw:1,0 -d 5 -f S16_LE -c1 -r44100

this does not show any error in the log.
But if i replace the last line with this

/usr/bin/arecord -D plughw:1,0 -d 5 -f S16_LE -c1 -r44100 | /usr/bin/aplay -D plughw:1,0

i get:

aplay: main:831: audio open error: Device or resource busy

[bpa]

The Waveinput plugin does nothing with audio subsystem - all it provides is a mechanism to enable a "wavin://" type url to be valid and then parse the URL to pass on a parameter to a command line to be executed whose output to stdout is a CD quality PCM, Flac or MP3 stream is then taken by LMS and sent to players. This is why plugin works on any LMS System Linux (ALSA, PulseAudio), Windows or OSX - just the arecord, parecord, ecasound or wavincmd.exe needs to run according to the OS and Audio subsystem - plugin doesn't change .

So the issue are in the command line/script or the environment in which the script is being run.

I don't know or have PCP, I use Ubuntu.
I'll run a few test with a simple USB audio adapter I have on which your arecord/aplay command line behaves as expected from a shell prompt - haven;t tested within LMS.

The areas I'll look include
* Arecord and aplay are the same program just the name implicitly uses the -P or -C option but opening "same" device. Should dmix be used .
* plughw:1,0 are s/w devices over hw: devices - shoudl hw: be used ?
* Your script looks very complicated with redirection of fds,. Could the aplay error referring to problems in open stdout.
* Is LMS being run as a service - if so different set of permission apply. I cannot test this.

On your system what hw/plughw device is being used for default audio sounds (i.e ALSA sysdefault ?)

[bpa]

I did some test with USB audio adapter (mic in - , speaker out) which appears as hw:2,0 on my Ubuntu.

When running my LSM on Ubuntu as a process, the command below worked ok, "wavin pcm" was the only entry custom-convert.conf I removed flac and mp3.
I enable player.source logging to INFO. I run LMS from a Konsole so I get all message sent to stderr so areplay and arecord output is visble as well as LMS logging.
I used tee to save output just in case.

[23-03-27 11:15:07.1176] Slim::Player::Songpen (361) wavin:abc
[23-03-27 11:15:07.1180] Slim::Player::TranscodingHelper::getConvertCommand 2 (490) Error: Didn't find any command matches for type: wavin
[23-03-27 11:15:07.1181] Slim::Player::Songpen (393) seek=false time=0 canSeek=0SEEK_ERROR_REMOTE
[23-03-27 11:15:07.1183] Slim::Player::TranscodingHelper::getConvertCommand 2 (493) Matched: wavin->pcm via: [arecord] -D plughw:2,0 -f S16_LE -c1 -r44100 | tee /tmp/test1.wav | [aplay] -D plughw:2,0
[23-03-27 11:15:07.1184] Slim::Player::Songpen (423) Transcoder: streamMode=R, streamformat=pcm
[23-03-27 11:15:07.1184] Slim::Player::Songpen (478) Opening stream (no direct streaming) using Plugins::WaveInput::WAVIN [wavin:abc]
[23-03-27 11:15:07.1187] Slim::Player::TranscodingHelper::tokenizeConvertCo mmand2 (667) Using command for conversion: "/usr/bin/arecord" -D plughw:2,0 -f S16_LE -c1 -r44100 | tee /tmp/test1.wav | "/usr/bin/aplay" -D plughw:2,0
[23-03-27 11:15:07.1274] Slim::Player::Songpen (508) URL is a song (audio): wavin:abc, type=pcm
[23-03-27 11:15:07.1296] Slim::Player::StreamingController::_Stream (1283) 9c:9c:1f:f2:c8:30: stream
[23-03-27 11:15:07.1308] Slim::Player::StreamingController::_Stream (1320) Song queue is now 0
[23-03-27 11:15:07.1311] Slim::Player::StreamingController::_setPlayingStat e (2378) new playing state BUFFERING
[23-03-27 11:15:07.1312] Slim::Player::StreamingController::_setStreamingSt ate (2387) new streaming state STREAMING
Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
[23-03-27 11:15:07.2556] Slim::Player::Player::_buffering (1161) Buffering... 0 / 261120
[23-03-27 11:15:07.5564] Slim::Player::Player::_buffering (1161) Buffering... 0 / 261120
[23-03-27 11:15:07.8572] Slim::Player::Player::_buffering (1161) Buffering... 0 / 261120

This test proves the issues is not LMS but environment.

At a shell prompt I tested the command
/usr/bin/arecord -D plughw:2,0 -f S16_LE -c1 -r44100 | /usr/bin/aplay -D plughw:2,00

It worked OK when system audio was on a different device but if system audio got swapped to the USB or if system audio stated to be used after first test - then I got aplay error message.

On your Pi - if there is no other audio output h/w - then system audio is being shared with your output. Not sure how to solve on PCP- perhaps enable headphone socket.
If there is other audio h/w check how defautl audio device is setup.

Separately your command could be simplified by using alsaloop command if available. Using plughw will ensure input and out audio stream are compatible and so no need for format command line options.
alsaloop -C plughw:2,0 -P plughw:2,0

[DerTeufel]

I did some test with USB audio adapter (mic in - , speaker out) which appears as hw:2,0 on my Ubuntu.

When running my LSM on Ubuntu as a process, the command below worked ok, "wavin pcm" was the only entry custom-convert.conf I removed flac and mp3.
I enable player.source logging to INFO. I run LMS from a Konsole so I get all message sent to stderr so areplay and arecord output is visble as well as LMS logging.
I used tee to save output just in case.

[23-03-27 11:15:07.1176] Slim::Player::Songpen (361) wavin:abc
[23-03-27 11:15:07.1180] Slim::Player::TranscodingHelper::getConvertCommand 2 (490) Error: Didn't find any command matches for type: wavin
[23-03-27 11:15:07.1181] Slim::Player::Songpen (393) seek=false time=0 canSeek=0SEEK_ERROR_REMOTE
[23-03-27 11:15:07.1183] Slim::Player::TranscodingHelper::getConvertCommand 2 (493) Matched: wavin->pcm via: [arecord] -D plughw:2,0 -f S16_LE -c1 -r44100 | tee /tmp/test1.wav | [aplay] -D plughw:2,0
[23-03-27 11:15:07.1184] Slim::Player::Songpen (423) Transcoder: streamMode=R, streamformat=pcm
[23-03-27 11:15:07.1184] Slim::Player::Songpen (478) Opening stream (no direct streaming) using Plugins::WaveInput::WAVIN [wavin:abc]
[23-03-27 11:15:07.1187] Slim::Player::TranscodingHelper::tokenizeConvertCo mmand2 (667) Using command for conversion: "/usr/bin/arecord" -D plughw:2,0 -f S16_LE -c1 -r44100 | tee /tmp/test1.wav | "/usr/bin/aplay" -D plughw:2,0
[23-03-27 11:15:07.1274] Slim::Player::Songpen (508) URL is a song (audio): wavin:abc, type=pcm
[23-03-27 11:15:07.1296] Slim::Player::StreamingController::_Stream (1283) 9c:9c:1f:f2:c8:30: stream
[23-03-27 11:15:07.1308] Slim::Player::StreamingController::_Stream (1320) Song queue is now 0
[23-03-27 11:15:07.1311] Slim::Player::StreamingController::_setPlayingStat e (2378) new playing state BUFFERING
[23-03-27 11:15:07.1312] Slim::Player::StreamingController::_setStreamingSt ate (2387) new streaming state STREAMING
Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
[23-03-27 11:15:07.2556] Slim::Player::Player::_buffering (1161) Buffering... 0 / 261120
[23-03-27 11:15:07.5564] Slim::Player::Player::_buffering (1161) Buffering... 0 / 261120
[23-03-27 11:15:07.8572] Slim::Player::Player::_buffering (1161) Buffering... 0 / 261120

This test proves the issues is not LMS but environment.

At a shell prompt I tested the command
/usr/bin/arecord -D plughw:2,0 -f S16_LE -c1 -r44100 | /usr/bin/aplay -D plughw:2,00

It worked OK when system audio was on a different device but if system audio got swapped to the USB or if system audio stated to be used after first test - then I got aplay error message.

On your Pi - if there is no other audio output h/w - then system audio is being shared with your output. Not sure how to solve on PCP- perhaps enable headphone socket.
If there is other audio h/w check how defautl audio device is setup.

Separately your command could be simplified by using alsaloop command if available. Using plughw will ensure input and out audio stream are compatible and so no need for format command line options.
alsaloop -C plughw:2,0 -P plughw:2,0

thank you very much. Sorry for coming back to this late...had to organize some usb audio input device for my raspi. No idea, why this wasn't working on my Pc. on the pi it is fine with this:

/mnt/data/slimserver/Cache/InstalledPlugins/Plugins/WaveInput/custom-convert.conf:

#
# wavin
#
wavin pcm * *
# R
/mnt/data/slimserver/Cache/InstalledPlugins/Plugins/WaveInput/audio.sh
wavin mp3 * *
# RB:{BITRATE=-B %B}
/mnt/data/slimserver/Cache/InstalledPlugins/Plugins/WaveInput/audio.sh

/mnt/data/slimserver/Cache/InstalledPlugins/Plugins/WaveInput/audio.sh:

#!/bin/bash

((
kill $(pidof alsaloop)

echo "starting alsaloop..."
/usr/local/bin/alsaloop -C plughw:1,0 -P plughw:2,0 -c 2 -t 20000
) 2>&1) | tee $PWD/audio.log

[bpa]

thank you very much. Sorry for coming back to this late...had to organize some usb audio input device for my raspi. No idea, why this wasn't working on my Pc. on the pi it is fine with this:

I haven't followed thread in detail so I don;t know what was the failed PC setup so I can't comment but permissions and group membership are the most usual issue.

The use of Waveinput to run a process is strange and I'm sure there is a better way to solve this.
IIRC on PCP I thought there was an ability to define some "user" scripts and then select and run one on command.

For LMS to run Waveinput an SB player has to be online and connected to LMS as LMS creates HTTP/GET connection to the player.

If there is no player connected to LMS and "wavin://" is played - nothing will happen - the alsaloop process will not be started.
If there is a player connected to LMS , then the SB player will be "in-use" without any audio while "wavin://" is playing and nothing can be played on that player.
I'm not sure what happens if no data is sent on that pipe for a long period.
If no data is sent on the connection, it's possible for some player (maybe a s/w one) a timeout might happen and so the "alsaloop" process will be killed unexpectedly.

[robertut]

According to LMS Command Line Interface documentation, it is possible to send an input source selection command from LMS to the Transporter hardware player:

Transporter Digital Inputs
Transporter Digital Inputs are handled as remote streams, with a URL starting with source: followed by aes-ebu, bnc-spdif, toslink or rca-spdif.
To set Transporter to the TOSLINK input, use <playerid> playlist play source:toslink
When set to a digital input, Transporter reports the URL scheme above to the various path, url or status queries.

Would be nice to be able to support this kind of usage through squeezelite.
I've submitted a feature request: https://github.com/ralph-irving/squeezelite/issues/179

[DerTeufel]

H,

till now, this (hacky) solution is working very well for me.
Now i decided to buy an optical audio adapter, to make use of this, instead of the headphones out.
But since the TV does not offer a way to control the volume of that output, I would need to control it on the Pi side.
Any ideas what i need to do, to be able to? Using ssh for alsamixer is not the best solution

[bpa]

Not sure what you ended up doing.
If there is a dummy SB player associated with this audio stream (i.e. the one which is playing wavin://) - then I think you could use Event trigger on a volume change on the player to issue a "amixer" command to change the volume.

[DerTeufel]

Not sure what you ended up doing.
If there is a dummy SB player associated with this audio stream (i.e. the one which is playing wavin://) - then I think you could use Event trigger on a volume change on the player to issue a "amixer" command to change the volume.

Great idea regaring "Event trigger" and "amixer".
Ahhhh... I was about to ask what "SB player" stands for...I have Squeezelite running on the box as well.

[DerTeufel]

Event trigger is doing great. Also using this now, to kill alsaloop, if the playlistitem is different from 'Waveinput'.
I also tried to stop "misusing" your plugin...
for testing I added a 1 second audio, and when this was being played, "Event trigger" was supposed to start the script (which currently is being started by your plugin). By doing so, alsaloop kept failing, telling the device already being busy (squeezelite using it), even though, the 1 second audio already had stopped again.

[bpa]

Normally, squeezelite will keep the alsa device open as long as the player is connected LMS. Use the "-C" option (only supports integers) to tell squeezelite to close the device (i.e free it up) when idle after x seconds- not sure of the timing might be too long but try "-C 1" but if squeezelite closes the device then I'm not sure if vol control will happen.

[DerTeufel]

I am not clear about to which cmd I should be adding the "-C 1" parameter. Could you please clarify?

[bpa]

I am not clear about to which cmd I should be adding the "-C 1" parameter. Could you please clarify?

The "-C 1" is added to the squeezelite command line - it helps squeezelite to share an output device with other audio application such as bluetooth.
Squeezelite will remain in contact with LMS but it doesn't open the alsa device until there is audio to play - and when all audio is finished after the timeout value in seconds - squeezelite closes the alsa device and so releases it to be available to other applications.