Go Back   Home > Forums > >
Home Forums Rules Articles diyAudio Store Blogs Gallery Wiki Register Donations FAQ Calendar Search Today's Posts Mark Forums Read

PC Based Computer music servers, crossovers, and equalization

A bash-script-based streaming audio system client controller for gstreamer
A bash-script-based streaming audio system client controller for gstreamer
Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 24th June 2016, 01:43 AM   #11
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Michigan
I have a question for some Linux savvy people out there about automating SSH login from one machine (computer A)to another (computer B) so that a script running on A can execute processes on B.

I have seen some suggestions for a program called "sshpass". Installation and use is very simple:
Code:
sshpass -p your_password ssh user@hostname
Sshpass would work great for my needs, except the login password to B will need to be kept in an unprotected text file on A.

Another option I have seen uses OpenSSH to generate a pair of keys, one of which is put into a special directory on B while the other resides on A. Info on this process can be found here for example:
SSH login without password
This is more complicated and there would be more for the user to do to set it up.

If the password contained in the unprotected text file for sshpass is just for a Raspberry Pi type computer running on and accessed only on the LAN, is that kind of security risk really of concern?

I think I could do the following: supply the program so that it will use sshpass but leave a configuration variable that the user can switch over to another SSH implementation if they so desire, e.g. one that is more secure, however they would need to set it up themselves. Does that sound like a good compromise?
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins

Last edited by CharlieLaub; 24th June 2016 at 01:52 AM.
  Reply With Quote
Old 24th June 2016, 03:34 AM   #12
pcgab is offline pcgab  United States
diyAudio Member
 
Join Date: Dec 2014
Location: San Marcos, Texas
A bash-script-based streaming audio system client controller for gstreamer
I would use ssh keys, it's really easy and OpenSSH has some built in tools to help, IIRC. 'ssh-copy-id'

https://www.digitalocean.com/communi...up-ssh-keys--2

Now to be clear, I'm a Linux Systems Engineer, so maybe some large salt grains should be taken with my opinion.

  Reply With Quote
Old 24th June 2016, 07:35 AM   #13
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Using keys is the correct way of automating ssh connections. As mentioned ssh-copy-id is trivial to use.

Of course it requires the ssh daemon to accept plaintext passwords for the initial key transfer. Most distributions have that disabled for root accounts.
  Reply With Quote
Old 24th June 2016, 02:53 PM   #14
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Michigan
Quote:
Originally Posted by pcgab View Post
I would use ssh keys, it's really easy and OpenSSH has some built in tools to help, IIRC. 'ssh-copy-id'

https://www.digitalocean.com/communi...up-ssh-keys--2

Now to be clear, I'm a Linux Systems Engineer, so maybe some large salt grains should be taken with my opinion.

Actually, thanks for the advice (and Phofman, too).

I think the most versatile path forward would for me to set up a CONFIG variable that holds the command that should be used for ssh. As supplied by me, this variable would initially be empty. I will give instructions on how to set up the system for sshpass, since that is brainless. But it is just as easy for the user to create keys and use ssh that way, however, I do not want to try and support that myself but will instead mention that possibility and direct the user to go and figure it out for themself. In that way, I can allow for multiple possibilities that will satisfy a variety of needs.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 25th June 2016, 05:41 PM   #15
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Michigan
I've been thinking a little more about how far I want to expand the capabilities of this software. I think that I can do a bit more now that I have build most of the client side scripting.

The new capabilities including controlling the bit depth and sample rate of the streamed audio, and controlling the receiving gsteramer pipeline on the client and launching user-specified "other programs". For example, in my system I use gstreamer to send (from the server) and receive (on each client) the streaming audio. I then use ecasound to implement a crossover on each client and send the audio via DACs to onboard amplifiers. So, for a loudspeaker to begin playing sound all of these processes need to be launched and when the loudspeaker should stop playing all these processes should be killed. I have already build a system for tracking the PID of the gstreamer process on the server side - the gstreamer pipeline PID is written to a file and this is used to kill the process when that is needed. I can do the same on the client side - record the PIDs for gstreamer and for any "other" programs such as ecasound that the user would like to launch and then kill those PIDs when the system is to be shut down. Having this type of control, and the ability to specify arbitrary "other programs" will significantly expand the capabilities of the control system.

As part of this I realized that I could allow the user to specify the bit depth and sample rate for the stream. Perhaps you have a system where the DACs are only capable of up to 16bit, 48kHz while on other systems you have 24/96 or 24/192 DACs. Each system can have its own capabilities specified, and multiple instances of the same system but with different capabilities could be implemented. This would allow one to, for example, compare 16/48 playback quality with 24/96 using the same system.

I am currently figuring out how I can implement these features, but it seems to be doable at this time. I will post about my progress with these features as they are put in place.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 7th July 2016, 08:12 PM   #16
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Michigan
UPDATE:
Got diverted away from this project for awhile but have now been able to pick it up again. Still making progress. Since my last post I decided on how the user can specify all sorts of server and client specific parameters, etc. Then I changed my mind and set it up a different way. Then I decided that still another approach would be better! Now I finally seem to have something that works well and is sufficiently flexible for my needs.

I hope to do some re-testing of the server-side stuff and then move on to implementing the client side. I will post more updates and test results here.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 9th July 2016, 04:35 AM   #17
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Michigan
update: I'm still swimming in the coding/testing cycle and it's coming together nicely.

Learning for the first time about things like the "eval" command, packing command arguments into arrays, here-document processing. Cool stuff.

I'm pushing 1k lines now... just 'a bit' more than I originally expected. Luckily I like coding, and this has been a fun bash-shell-script learning experience.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 12th July 2016, 12:49 AM   #18
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Michigan
OK, I'm finally having some success!

But at the same time I am having some very frustrating challenges that my weak BASH Fu is not able to overcome...

So I have managed to code up script that can launch and terminate gstreamer pipelines on both a "server" computer (where the audio source is found, e.g. a player such as mpd) and any number of "client" computers (for me these are raspberry pis) that comprise one or more loudspeaker or playback systems, or audio sinks if you prefer that term. This is the main functionality that I was hoping to achieve, so that is a great success!

But, to extend this and make it more flexible and powerful I was hoping that I could have the user specify multiple "other" commands that would be run on the client computer. For me, the main one is ecasound, the program that I use to implement the crossover on the R-Pi before spitting out the audio thru DACs to amps to the speakers. This parts is giving me a lot of problems.

The user specifies a sting of ";" separated commands in a text file on the server. Things like:
cd ~/somedir; ./my_script.sh
The dirty details is that I am logging into the clients using ssh and then running these commands. If they are simple things like echo "hello world" or even echo $! it works! But when the ssh session logs out the terminal is closed and any and all commands that are still running are SIGTERMinated and stop running.

Ah, you say. I know BASH and you just need nohup. Well this isn't working for me via the ssh session. It DOES work, however. I know this because I did a check by logging in manually using a different type of ssh program. Then I ran the shell script with the nohup preceding my ecasound commands and put it in the background. Then I logged out of that session and logged back in again. It was still running. When I call the exact same thing from my script, it always is killed off. So I am a bit perplexed.

If anyone knows BASH quite well and wants to help me out, feel free to drop me a line.

In the meantime I will keep working to see if I can find another solution to the problem.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 12th July 2016, 04:07 PM   #19
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Michigan
After 12 hours of banging my head against my keyboard, I seem to have BASHed my way to success (pun intended).

It turned out that the ssh session on/to the client only gets a subset of the full complement of environmental variables. For instance the TERM and COLUMNS variables are left unset. For simple commands like echo or pwd this was not a problem. I was, however, wanting to run my ecasound command string. It's a multi-line thing, so I put it in a shell script. Every time I attempted to run it I got the error "TERM environmental variable not set". I first tried setting the TERM variable in the ecasound shell script, and later tried setting it in the HERE-DOCUMENT that was being piped to ssh, but neither of these worked. The fix I discovered was to set all (missing) environmental variables in the line where ssh is invoked so that these are adopted by the ssh session from the beginning, like this:
Code:
ssh user@host ARG1="value1" ARG2="value2" /bin/bash << ENDSSH
  # commands to run on remote host
  # ARG1 and ARG2 are now environmental variables within the ssh session on the client
  lines of code that are run on the client go here...
ENDSSH
These included the LADSPA_PATH and the COLUMNS variable. To make it possible for the user to set these environmental variables I will try to add another line to the system configuration file that the user can populate with the necessary text. Hopefully that will work, because these can't really be known in advance and hardcoded into the script.

One side benefit from my diagnostic work on the above problem was that I discovered that it is possible to run a script that is located on the SERVER on the CLIENT using ssh. One interesting application of this would be to store the ecasound script on the server instead of on the client. This might make it easier to implement changes to the ecasound string because the server probably has a head (a monitor) while the client is often headless (no monitor or input devices). The ecasound command runs in an identical fashion regardless of where the script is located, so I will think about how I might make both of these options possible (script located on client or on the server) and what would be easier to understand for the user. Locating scripts on the server is a way to centralize everything in one place.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 12th July 2016, 05:21 PM   #20
3ll3d00d is offline 3ll3d00d  United Kingdom
diyAudio Member
 
3ll3d00d's Avatar
 
Join Date: Jan 2014
wouldn't you want those env vars to be managed on the client as they might be client specific values?
  Reply With Quote

Reply


A bash-script-based streaming audio system client controller for gstreamerHide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
New BeagleBone based Audio System dogrocket Vendor's Bazaar 3 1st April 2016 04:02 AM
XMOS audio streaming controller GB interest heartwinter Group Buys 12 13th July 2015 04:30 PM
USB streaming controller arjunm009 Digital Line Level 2 12th May 2015 04:38 AM
First audio project, Wall controller for room audio system, looking for guidance, Chrisdvip Construction Tips 2 10th June 2013 05:47 AM
Audio System Controller happyboy Analog Line Level 9 12th September 2012 09:12 AM


New To Site? Need Help?

All times are GMT. The time now is 08:59 AM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2018 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 14.29%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2018 DragonByte Technologies Ltd.
Copyright ©1999-2018 diyAudio
Wiki