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 18th March 2018, 08:03 AM   #101
hopkins is offline hopkins  France
diyAudio Member
 
Join Date: Feb 2012
Location: Paris
You stated above that you were running two usb DACs on a single Pi in an active crossover system. I was under the impression that two usb outputs on one card could not guarantee synchronicity as the DACs buffer the data with a USB input. Is that not the case? The question is unrelated to your software, but I was curious to know.
  Reply With Quote
Old 18th March 2018, 12:51 PM   #102
DonVK is offline DonVK  Canada
diyAudio Member
 
DonVK's Avatar
 
Join Date: Jan 2017
Location: Ottawa
In addition to DAC skew (delta buffer depth) there is also the potential of clock drift (bit sync). I'm not sure how these DACs replay, if its a local oscillator or pll'd to input stream.

Is there a way to determine how much of the cpu usage is related to servicing those 2 USB dacs?
  Reply With Quote
Old 18th March 2018, 03:41 PM   #103
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
A bash-script-based streaming audio system client controller for gstreamer
Quote:
Originally Posted by hopkins View Post
You stated above that you were running two usb DACs on a single Pi in an active crossover system. I was under the impression that two usb outputs on one card could not guarantee synchronicity as the DACs buffer the data with a USB input. Is that not the case? The question is unrelated to your software, but I was curious to know.
You raise a very good point. Gstreamer can actually deal with this situation by resampling the audio or skewing the playback pointer to each DAC (separately) to account for different consumption rates by the DAC due to slightly different DAC clocks. Forum member phofman has done some experiments with this feature and he can comment in more detail.

This doesn't have anything to do with buffering by the DAC, it the consumption rate of data that differs due to clock differences. Each will have a slightly different idea of "time" when they have an onboard crystal. For adaptive mode DACs, the DACs get their time reference from the USB bus clock, which is not all that accurate but will keep multiple DACs operating "together" perfectly. In either case, gstreamer can adjust the rate that data is sent to the DAC or add/remove samples to account for the difference between the reference clock that gstreamer is using and the DAC clock.

Previously when using ecasound I used NTP to keep the clocks on each endpoint (e.g. the Pi) running at the same rate as the computer sending the audio to them. Gstreamer has now implemented something like NTP as part of its RTP audio streaming functionality, and you can use it to slave the "receiver" pipeline clock to the "sender" pipeline clock without having to run NTP on either machine. In this way, you can have a single clocksource set the rate for pipelines on two different machines. It's not as important for that clock to be perfectly accurate (what is perfectly accurate anyway?) as it is for that single clock to be used as the time reference for all participants in the playback chain so that buffer under/overruns are prevented.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 18th March 2018, 08:19 PM   #104
hopkins is offline hopkins  France
diyAudio Member
 
Join Date: Feb 2012
Location: Paris
Quote:
Originally Posted by CharlieLaub View Post
You raise a very good point. Gstreamer can actually deal with this situation by resampling the audio or skewing the playback pointer to each DAC (separately) to account for different consumption rates by the DAC due to slightly different DAC clocks. Forum member phofman has done some experiments with this feature and he can comment in more detail.

This doesn't have anything to do with buffering by the DAC, it the consumption rate of data that differs due to clock differences. Each will have a slightly different idea of "time" when they have an onboard crystal. For adaptive mode DACs, the DACs get their time reference from the USB bus clock, which is not all that accurate but will keep multiple DACs operating "together" perfectly. In either case, gstreamer can adjust the rate that data is sent to the DAC or add/remove samples to account for the difference between the reference clock that gstreamer is using and the DAC clock.

Previously when using ecasound I used NTP to keep the clocks on each endpoint (e.g. the Pi) running at the same rate as the computer sending the audio to them. Gstreamer has now implemented something like NTP as part of its RTP audio streaming functionality, and you can use it to slave the "receiver" pipeline clock to the "sender" pipeline clock without having to run NTP on either machine. In this way, you can have a single clocksource set the rate for pipelines on two different machines. It's not as important for that clock to be perfectly accurate (what is perfectly accurate anyway?) as it is for that single clock to be used as the time reference for all participants in the playback chain so that buffer under/overruns are prevented.
Thanks for your reply. Interesting. I wonder how this can be tested. Small timing differences may not be so obvious to detect - I don't know...

There would defenitely be a benefit to having perfect timing and being able to use two SBCs as opposed to going to multiple channel solutions which are not common/easy to implement, at least with Raspberry Pis. I could see using this setup with two Raspberry Pi, a good digital hat (ex Allo DigiOne) and full digital amplifiers, to keep the entire audio chain in the digital domain at a reasonable cost.

Last edited by hopkins; 18th March 2018 at 08:28 PM.
  Reply With Quote
Old 19th March 2018, 03:22 PM   #105
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
A bash-script-based streaming audio system client controller for gstreamer
Quote:
Originally Posted by phofman View Post
Perhaps looking at python would make your project in the long run easier. Complicated bash scripts are difficult to maintain (workarounds due to limited language, no debugging etc.). Today I would not use bash for a project of this scale.

Hats off to what you have achieved.
Actually, I think the bash approach might have one interesting advantage: there is a very good chance that I can run nearly the same bash script under Windows-10 Windows Subsystem for Linux. There are gstreamer Windows binaries available and I think I can connect to the Windows audio susbstem via gstreamer's wasapi element. The rest of the server pipeline is assigning channels and then streaming them to clients over RTP/UDP. The script also needs to make use of ssh, however, since it is all text based (no GUI) it should be available under WSL. Clients would still need to be linux boxes, since LADSPA is not practically possible under Linux. LADSPA is not used on the server side, so no problem there.

I think it would be very interesting if GSASysCon could run server-side under Windows 10 WSL, with clients being small Linux machines like the Raspberry Pi, Asus Tinkerboard, etc.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 19th March 2018, 06:20 PM   #106
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Nothing against bash in linux subsystem for windows, but a decently written python script is portable directly, distributed e.g. using Welcome to PyInstaller official website — PyInstaller .
  Reply With Quote
Old 20th March 2018, 01:19 AM   #107
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
A bash-script-based streaming audio system client controller for gstreamer
Quote:
Originally Posted by phofman View Post
Nothing against bash in linux subsystem for windows, but a decently written python script is portable directly, distributed e.g. using Welcome to PyInstaller official website — PyInstaller .
Well, OK, I did not know about that possibility. Anyway, I have very little programming experience in Python, and even if I did it would be a significant undertaking to duplicate the bash script in python....

In the meantime I have been looking into how to run GSASysCon under Windows. It looks like the Windows Subsystem for Linux can run the script, and I can even install Gstreamer under WSL (or so it seems). Most everything is in place, really. The main hurdle seems to be accessing audio from Linux applications running under WSL. ALSA is not implemented AFAIK and while there are some attempts at porting pulse audio to WSL, they seem to already be outdated.

What could be done, is to use local streaming to send audio from (native) Windows to WSL. I actually have some experience with this - in the past I did it using FFmpeg, which can stream RTP in UDP but only to a local port. That's exactly what we need here. A Windows audio app would send audio to FFmpeg or FFmpeg would capture it using DirectShow. FFmpeg would resample the audio to the desired stream sample rate (this is fixed under GSASysCon) and the stream it to a local port, e.g. 127.0.0.1:1234. Then under WSL GSASysCon would use that RTP/UDP stream as input, and would restream it to clients as usual. FFmpeg has a very good resampler built in and it is highly configurable. Local streaming is quite low latency, so I think this would work well and wouldn't require any new code to GSASysCon.

WSL is pretty amazing, and it seems to be implemented well. I'm hopeful about using it to make it possible to use GSASysCon on a Windows box.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 6th April 2018, 02:00 PM   #108
flangaman is offline flangaman  Italy
diyAudio Member
 
Join Date: Sep 2014
Location: Treviso (near Venice) - ITALY
Hi Charlie,

I am very interest about your project that I have traced from first steps (2015) on your threads.
I have to say that I am not able to understand everything you write, not in depth, but only the general aspects and the problems that you face.

I am working on a unconventional speaker system where a coaxial loudspeaker (6.5" woofer + 1" compression tweeter) works horizontally on top panel of case. Over it an acoustic lens projects the sound around, while the modeled surface of the top panel works together it like a horn and wave guide.
A similar spread head scheme is shown on some omnidirectional Duevel loudspeakers, however my spread head is divided in 4 (or 5) wave guides that lead the sound not only horizontally but, where necessary e with different angles, upward (for example to avoid sound reflections from side walls as happen with a dipole acoustic, see Sigmund Linkwitz's site) to climb over the listener and get lost at the back of the room. My speaker system is not omnidirectional.

I have described the way in which it is unconventional, for tell you that it is much more susceptible to temporal misalignments than a traditional system can be.
When the two speakers are well positioned the scene is very large, width and deep. A really tridimensional and natural sound.
Is difficult to believe but if now you move a speaker forward also less than 1 cm (0.39") is noticeable that the scene narrows a little and begins to become asymmetrical. Nota bene, the guitar that was in center is still in center, to move it could be not enough a movement forward 10 times larger.
And indeed the balance control is ineffective on "ambience" that is instead dominated by precedence effect.

On the other end in case of temporal shift of sound emission between speakers only the precedence effect is involved, there is not a SPL gap, while in case of a physical misalignment of speakers both play a role. Is difficult to foresee the behavior, but we should expect a wavering scene.
Well, at first of your project you measured a time shift greater than a 50 msec, then with a realignment process is passed to 1 msec (34.5 cm or 13.6") and then 0.5 msec (17.25 cm or 6.8" = +-8 cm, still too much for me).
But recently you have improved the process to obtain until 0.006 msec (2.07 mm ! = +- 1 mm) that "..is really pretty darn good." (#38)

Then on UsageTips.txt I read "the synchronization could be held to better than 0.02 milliseconds. A delay of 2 milliseconds can result in audible artifacts, but 0.02 msec will not.", and probably you are right but, even if I have not yet tried, I would rather 0.006 msec.
Is there a more extreme setting (maxpoll>5)?

Can I query GSASysCon system on run about left/right channels latency, or is it unaware of it?

What does it mean "By setting my NTP server to poll internet timeservers on a long time scale, and setting all local computers to poll my server on a very short timescale.."?
Does it mean that a server is always active to query internet timeservers? Instead if I turn on the server right now, how long does it take to stabilize the system?
In general I understand that you want both the server and the clients to always be on, but I do not understand why. Can you explain what it is for?

It is stupid, but I am anxious that devices to be on even when I am not using them.

And if "The goal is NOT to get accurate time/date on each client, but rather to get their clocks running at the same RATE", and can not use a internal clock of server itself because it is not accurate enough, can I to connect Raspberry to a re-clock card, for e.g. ALLO – Kali i2s Reclocker?
Is it a usable mode?

A question again, I desire use class-D amps like: IQaudIO Pi-DigiAMP+ (44.1-192kHz 16-24bit), HiFiBerry Amp2 (44.1-192kHz 16-32bit) or Beocreate 4 channel amplifier (44.1-192kHz 16-24bit).
These have not inputs USB but use ".. the digital I2S audio signals to reduce CPU load over USB audio solutions", is it a problem?
Can they be used?

Congratulations on your work in this project, for ACD and ACD-L and for the software collection hosted on your site.

Thank you,
Flavio Manganelli
  Reply With Quote
Old 6th April 2018, 05:12 PM   #109
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
A bash-script-based streaming audio system client controller for gstreamer
The synchronization issue is only when there are multiple playback clients. For instance if you use a Raspberry Pi in each speaker. In contrast, when the system uses only one playback client and that client uses one DAC, synchronicity is not an issue (it will be perfect for all channels). In your case, I suggest you consider using one SBC or computer and a multichannel DAC. I2S-input amplifiers are usually not more than 2 channels. The only exception in your list is the Beocreate amp, which is 4 channels, but I think there are better options in terms of amplification for what it costs.

Using a multichannel USB DAC and analog input amplifiers will make things much easier for you. I have started to prefer pro audio recording interfaces because they have good quality inputs (ADC) and the analog (DAC) output level can often be 2Vrms or more. This also allows you to use the SBC/computer like a hardware crossover. If the audio interface has multiple inputs, you can use the system like a DSP preamp, switching between inputs.

Glad to hear that you are using my tools (like ACD) and streaming audio controller! I'm happy to receive feedback, good or bad.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins
  Reply With Quote
Old 16th April 2018, 03:26 PM   #110
CharlieLaub is offline CharlieLaub  United States
diyAudio Member
 
Join Date: Mar 2007
Location: California
A bash-script-based streaming audio system client controller for gstreamer
I've been using the new code for a couple of weeks now and I am happy with it, so I will turn my attention to updating the documentation. This will mostly be to cover the new features of local playback, using the code to act as a local software DSP without streaming, etc.

I've only tried the code with my ACD LADSPA plugins. I will be releasing a version that doesn't change anything under the hood, but makes the parameter names easier to use since you set values by name under gstreamer instead of by position, e.g. with ecasound.

Should be just another week or two and then I can release it.

Since the code can now implement DSP in addition to streaming I will probably start a new thread and might rename the program to reflect that. I will post info here if/when that happens.
__________________
Visit my Audio Web Page <<--CLICK TO LEARN MORE-->> Get my LADSPA plugins

Last edited by CharlieLaub; 16th April 2018 at 03:32 PM.
  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 12:44 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