IPB

Welcome Guest ( Log In | Register )

3 Pages V   1 2 3 >  
Reply to this topicStart new topic
192Khz Lossless Audio LAN streaming, dshow filters
logicom
post Oct 13 2013, 11:25
Post #1





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929



Dear HA Community,

My task is to transport "untouched" audio from point to point in LAN.
However I have to use 192Khz 16bit sound resolution, in order to preserve additional information that is encoded in the audio, and that must remain unaffected.
Compression with one of Lossless Audio encoders would be beneficial ( ex. FLAC)

I am trying to do this:



I need help with a few things:

-what kind of container/multiplexer is supported with flac, in order to stream it (I suppose ogg but I cannot find dshow filter)
-could someone tell me how to finish this graph and send RTP stream to IP address.

Is there any other software which I could use for this purpose ? (jack is not an option)

Kind Regards.
Go to the top of the page
+Quote Post
phofman
post Oct 13 2013, 12:03
Post #2





Group: Members
Posts: 300
Joined: 14-February 12
Member No.: 97162



Why specifically is jack not an option?

Do you have any latency criteria?

I assume the encoded information in the stream requires bitperfect transfer.

Did you consider the issue of two different clock domains (the incoming spdif stream, the playback soundcard on a different machine)? Jack solves that by adaptive resampling.

In linux you could just pipe the stream to a different machine via netcat for processing. AFAIR netcat is available in cygwin.
Go to the top of the page
+Quote Post
logicom
post Oct 13 2013, 17:41
Post #3





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929



QUOTE (phofman @ Oct 13 2013, 13:03) *
Why specifically is jack not an option?

Do you have any latency criteria?

I assume the encoded information in the stream requires bitperfect transfer.

Did you consider the issue of two different clock domains (the incoming spdif stream, the playback soundcard on a different machine)? Jack solves that by adaptive resampling.

In linux you could just pipe the stream to a different machine via netcat for processing. AFAIR netcat is available in cygwin.


Thank you for replying.

I will try to clarify:
-encoded stream should be sent over both Ethernet and wifi connection.
As for NetJack it seems to be a problem working on a broadcast domain without collision detection.
I was thinking that flac might also reduce bandwidth requirements ex. from 6 to 4Mbytes/sec
act as encapsulation for PCM waveform(keeping it "bitperfect"), and by using reliable transport and introducing some buffer on the playout end, it would work.
-Latency is not an issue, but reliability.

On the recieving end there would be a soundcardcard supporting same clockrate, and player application would do buffering and re clocking. (I would have to rethink this)
But that's the idea.

-To simplify it should be bitperfect streaming over wifi for 192Khz. 16bit sound, preferably with lossless compression.


Thanks!


Go to the top of the page
+Quote Post
phofman
post Oct 13 2013, 22:15
Post #4





Group: Members
Posts: 300
Joined: 14-February 12
Member No.: 97162



If linux is an option:

Transmitting side:
CODE
sox Music/long-192-16.wav -t flac -r 192000 -b 16 - | pv | nc playback-host 5555


Receiving side (on playback-host)

CODE
nc --continuous --exec='mbuffer -m 20M -P 5 | sox  -t flac - -t alsa plughw:0' -l -p 5555


Since you are connecting two clock domains you have to make sure enough buffers are employed with enough cached samples at the beginning. Hence the mbuffer command - 20MB buffer, starts writing after 5 % (1MB) of samples buffered (for the case when playback clock is running faster than the incoming SPDIF stream). Of course the latency is large.

On the transmitting side you can read the samples from the SPDIF input and convert to flac both using sox


CODE
sox -t alsa plughw:YOUR_SPDIF_DEVICE -b 16 -r 192000 -t flac -r 192000 -b 16 - | pv | nc playback-host 5555


The commands pv on transmitting and mbuffer on the receiving side will nicely report current stream bitrates.

This post has been edited by phofman: Oct 13 2013, 22:16
Go to the top of the page
+Quote Post
logicom
post Oct 18 2013, 16:52
Post #5





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929



QUOTE (phofman @ Oct 13 2013, 23:15) *
If linux is an option:

Transmitting side:
CODE
sox Music/long-192-16.wav -t flac -r 192000 -b 16 - | pv | nc playback-host 5555


Receiving side (on playback-host)

CODE
nc --continuous --exec='mbuffer -m 20M -P 5 | sox  -t flac - -t alsa plughw:0' -l -p 5555


Since you are connecting two clock domains you have to make sure enough buffers are employed with enough cached samples at the beginning. Hence the mbuffer command - 20MB buffer, starts writing after 5 % (1MB) of samples buffered (for the case when playback clock is running faster than the incoming SPDIF stream). Of course the latency is large.

On the transmitting side you can read the samples from the SPDIF input and convert to flac both using sox


CODE
sox -t alsa plughw:YOUR_SPDIF_DEVICE -b 16 -r 192000 -t flac -r 192000 -b 16 - | pv | nc playback-host 5555


The commands pv on transmitting and mbuffer on the receiving side will nicely report current stream bitrates.


Thank you once again,

This certainly works, and I am willing to try it this weekend. Is there any solution for windows ?
Just for curiosity what would be the best way to go for ultra low latency ? (linux or windows)

Regards.
Go to the top of the page
+Quote Post
greynol
post Oct 18 2013, 17:09
Post #6





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



192 kHz and now low latency; I must ask, what is the application?


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
logicom
post Oct 18 2013, 19:36
Post #7





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929



QUOTE (greynol @ Oct 18 2013, 18:09) *
192 kHz and now low latency; I must ask, what is the application?

I am trying to transport encoded information in the sound along with the music. Like watermarking.
Go to the top of the page
+Quote Post
greynol
post Oct 18 2013, 19:42
Post #8





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



...and you're trying to do this in the analog domain?


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
logicom
post Oct 19 2013, 09:02
Post #9





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929



QUOTE (greynol @ Oct 18 2013, 20:42) *
...and you're trying to do this in the analog domain?

correct.
Go to the top of the page
+Quote Post
phofman
post Oct 21 2013, 09:07
Post #10





Group: Members
Posts: 300
Joined: 14-February 12
Member No.: 97162



IMO low latency = jackd. Low latency is its top focus.

BUT you will have to use the adaptive resampler zita-ajbridge if merging two clock domains - not bit perfect.

IMO the most reliable option with best results would be to run the SPDIF coax all the way to your playback machine and skip the wireless part.

Go to the top of the page
+Quote Post
Specy
post Oct 21 2013, 15:57
Post #11





Group: Members
Posts: 22
Joined: 27-November 08
Member No.: 63320



Are you by any chance working with MPX signals? If so, the sample rate can be lowered to ~ 128 kHz (there won't be any signal above 60 kHz if you don't use SCA channels), and if you really need to reduce bandwidth, you could get away with *slightly* lowering the bit depth (14 bits should still suffice).

Flac can be used to reduce the required bandwidth *on average*, however nothing can be guaranteed and you might at some points even get a (slightly) increased bandwidth - which, especially when combined with the low latency requirement, might be problematic.
Go to the top of the page
+Quote Post
logicom
post Oct 23 2013, 15:31
Post #12





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929



Thanks phofman,

your first suggestion is fine.

I really appreciate.

transporting MXP over IP is a nice example, but for my application I need to keep sound resolution.

Thank you all.
Go to the top of the page
+Quote Post
logicom
post Nov 1 2013, 22:30
Post #13





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929



I dont know how to ask linux nicely, but this is what i am getting:

a couple of problems here:

CODE
$ sox -t alsa plughw:0,1 -b 16 -r 192000 -t flac -r 192000 -b 16 - | pv | nc IP 5555

Input File     : 'plughw:0,1' (alsa)
Channels       : 2
Sample Rate    : 48000
Precision      : 16-bit
Sample Encoding: 16-bit Signed Integer PCM

In:0.00% 00:00:00.00 [00:00:00.00] Out:0     [      |      ]        Clip:0      sox WARN alsa: Input/output error                                              ]
sox FAIL sox: `plughw:0,1' Device or resource busy: Operation not permitted
In:0.00% 00:00:00.00 [00:00:00.00] Out:0     [      |      ]        Clip:0    
Done.
   0B 0:00:10 [   0B/s] [<=>


0,1 = Asus Xonar D1 digital audio capture

1. alsa alows me only 48k ?

2. on another linux host under vmware sending works partialy,but only with 48k settings and it breaks after a while... ?

in this case 0,0 = VAC
CODE
@UbuntuVM1:~$ sox -t alsa plughw:0,0 -b 16 -r 48000 -t flac -r 48000 -b 16 - | pv | nc IP 5555

Input File     : 'plughw:0,0' (alsa)
Channels       : 2
Sample Rate    : 48000
Precision      : 16-bit
Sample Encoding: 16-bit Signed Integer PCM

In:0.00% 00:00:00.85 [00:00:00.00] Out:36.9k [      |      ]        Clip:0      In:0.00% 00:00:01.88 [00:00:00.00] Out:86.0k [      |      ]        Clip:0      In:0.00% 00:00:03.07 [00:00:00.00] Out:143k  [      |      ]        Clip:0      In:0.00% 00:00:04.10 [00:00:00.00] Out:193k  [      |      ]        Clip:0      In:0.00% 00:00:05.12 [00:00:00.00] Out:242k  [      |      ]        Clip:0      In:0.00% 00:00:06.14 [00:00:00.00] Out:291k  [      |      ]        Clip:0      In:0.00% 00:00:07.17 [00:00:00.00] Out:340k  [      |      ]        Clip:0      In:0.00% 00:00:08.19 [00:00:00.00] Out:389k  [      |      ]        Clip:0      In:0.00% 00:00:09.22 [00:00:00.00] Out:438k  [      |      ]        Clip:0      In:0.00% 00:00:10.24 [00:00:00.00] Out:487k  [      |      ]        Clip:0      In:0.00% 00:00:11.26 [00:00:00.00] Out:537k  [      |      ]        Clip:0      In:0.00% 00:00:12.46 [00:00:00.00] Out:594k  [      |      ]        Clip:0      In:0.00% 00:00:13.48 [00:00:00.00] Out:643k  [      |      ]        Clip:0      In:0.00% 00:00:14.51 [00:00:00.00] Out:692k  [      |      ]        Clip:0      In:0.00% 00:00:15.53 [00:00:00.00] Out:741k  [      |      ]        Clip:0      In:0.00% 00:00:16.55 [00:00:00.00] Out:791k  [      |      ]        Clip:0      In:0.00% 00:00:17.58 [00:00:00.00] Out:840k  [      |      ]        Clip:0      In:0.00% 00:00:18.60 [00:00:00.00] Out:889k  [      |      ]        Clip:0      In:0.00% 00:00:19.63 [00:00:00.00] Out:938k  [      |      ]        Clip:0      In:0.00% 00:00:20.82 [00:00:00.00] Out:995k  [      |      ]        Clip:0      In:0.00% 00:00:21.76 [00:00:00.00] Out:1.04M [      |      ]        Clip:0      In:0.00% 00:00:22.78 [00:00:00.00] Out:1.09M [      |      ]        Clip:0      In:0.00% 00:00:23.47 [00:00:00.00] Out:1.12M [      |      ]        Clip:0       0B 0:00:22 [   0B/s] [<=>                                                   ]
In:0.00% 00:00:46.85 [00:00:00.00] Out:2.24M [      |      ]        Clip:0    @UbuntuVM1:~$



I am using Ubuntu 13.10 and flac 1.3.1

3. netcat syntax is different. Could you assist on the command line for the reciever side please?

Kind Regards.
Go to the top of the page
+Quote Post
logicom
post Nov 1 2013, 22:39
Post #14





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929



Windows aproach:

VAC->edcast->icecast2

sending works

reciever is foobar2000 and it plays the content something like 4 times slower and eventualy drop the connection and stop playing.
Output device is supporting 192Khz output but it looks like there is a player or encoder limitation... ? Winamp and VLC refuse to work.
Evrything works only with 44Khz.

Any suggestions ?

Regards.
Go to the top of the page
+Quote Post
phofman
post Nov 2 2013, 00:11
Post #15





Group: Members
Posts: 300
Joined: 14-February 12
Member No.: 97162



QUOTE (logicom @ Nov 1 2013, 23:30) *
In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0 sox WARN alsa: Input/output error ]
sox FAIL sox: `plughw:0,1' Device or resource busy: Operation not permitted


Your sound device is already used by another process, most likely pulseaudio. You can find out which by running

CODE
sudo lsof /dev/snd/*


QUOTE
1. alsa alows me only 48k ?


When capturing SPDIF input, you cannot select input samplerate on the soundcard. It is defined by the incoming stream. IMO you are feeding the card with 48k SPDIF.

QUOTE
2. on another linux host under vmware sending works partialy,but only with 48k settings and it breaks after a while...


Let's fix the capturing in non-virtualized environment first.

QUOTE
3. netcat syntax is different. Could you assist on the command line for the reciever side please?


There are two different netcat packages in your repo -
netcat-traditional and netcat-openbsd, each with a bit different feature set.
Go to the top of the page
+Quote Post
logicom
post Nov 2 2013, 10:26
Post #16





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929



quick update:

1. used by pulse audio is true:

CODE
:~$ sudo lsof /dev/snd/*
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
COMMAND    PID   USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
pulseaudi 1379 ./.   17u   CHR 116,10      0t0 10601 /dev/snd/controlC1
pulseaudi 1379 ./.   24u   CHR 116,10      0t0 10601 /dev/snd/controlC1
pulseaudi 1379 ./.   30u   CHR 116,15      0t0 10868 /dev/snd/controlC0
pulseaudi 1379 ./.   34u   CHR 116,15      0t0 10868 /dev/snd/controlC0


2. There is no input connected to the sound card

This post has been edited by logicom: Nov 2 2013, 10:27
Go to the top of the page
+Quote Post
logicom
post Nov 4 2013, 18:42
Post #17





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929



Ok,

here is capturing "working" on physical machine:

CODE
:~$ sox -t alsa plughw:D1,0 -b 16 -r 48000 -t flac -r 48000 -b 16 - | pv | nc 172.16.0.7 5555

Input File     : 'plughw:D1,0' (alsa)
Channels       : 2
Sample Rate    : 48000
Precision      : 16-bit
Sample Encoding: 16-bit Signed Integer PCM

In:0.00% 00:00:00.34 [00:00:00.00] Out:12.3k [      |      ]        Clip:0       0B 0:00:00 [   0B/s] [<=>                                                   ]
In:0.00% 00:00:00.51 [00:00:00.00] Out:20.5k [      |      ]        Clip:0    dr6 - | pv | nc 172.16.0.7 5555 plughw:D1,0 -b 16 -r 48000 -t flac -r 48000 -b 16

Input File     : 'plughw:D1,0' (alsa)
Channels       : 2
Sample Rate    : 48000
Precision      : 16-bit
Sample Encoding: 16-bit Signed Integer PCM

In:0.00% 00:00:00.34 [00:00:00.00] Out:12.3k [      |      ]        Clip:0       0B 0:00:00 [   0B/s] [<=>                                                   ]
In:0.00% 00:00:00.51 [00:00:00.00] Out:20.5k [      |      ]        Clip:0


and it fails after two cycles. What is next ?

Regards.

This post has been edited by logicom: Nov 4 2013, 19:06
Go to the top of the page
+Quote Post
phofman
post Nov 4 2013, 20:11
Post #18





Group: Members
Posts: 300
Joined: 14-February 12
Member No.: 97162



Does the other, receiving part run? It must be consuming samples, otherwise the transmitting part gets blocked after filling all the buffers in sox/pipes/netcat.
Go to the top of the page
+Quote Post
logicom
post Nov 5 2013, 18:33
Post #19





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929



QUOTE (phofman @ Nov 4 2013, 20:11) *
Does the other, receiving part run? It must be consuming samples, otherwise the transmitting part gets blocked after filling all the buffers in sox/pipes/netcat.


I switch to: /bin/nc.traditional

CODE
:~$ nc -h
[v1.10-40]


and now I am just getting this prompt after putting in command:

CODE
:~$ nc --continuous --exec='mbuffer -m 1M -P 5 | sox -t flac - -t alsa plughw:0,0 -l -p 5555
>


and cursor is blinking.

On sending host it happens exactly the same as I previously described. It fails after two cycles.

Regards.
Go to the top of the page
+Quote Post
phofman
post Nov 5 2013, 19:30
Post #20





Group: Members
Posts: 300
Joined: 14-February 12
Member No.: 97162



QUOTE (logicom @ Nov 5 2013, 19:33) *
CODE
:~$ nc --continuous --exec='mbuffer -m 1M -P 5 | sox -t flac - -t alsa plughw:0,0 -l -p 5555
>


and cursor is blinking.


Your exec command in nc is missing the closing singlequote, the shell waits for continuation of the command.

Plus do you have mbuffer installed?

QUOTE
On sending host it happens exactly the same as I previously described. It fails after two cycles.


Exactly, your receiving side is not running yet.

This post has been edited by phofman: Nov 5 2013, 19:45
Go to the top of the page
+Quote Post
logicom
post Nov 5 2013, 19:50
Post #21





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929



QUOTE (phofman @ Nov 5 2013, 19:30) *
QUOTE (logicom @ Nov 5 2013, 19:33) *
CODE
:~$ nc --continuous --exec='mbuffer -m 1M -P 5 | sox -t flac - -t alsa plughw:0,0 -l -p 5555
>


and cursor is blinking.


Your exec command in nc is missing the closing singlequote, the shell waits for continuation of the command.

Plus do you have mbuffer installed?

QUOTE
On sending host it happens exactly the same as I previously described. It fails after two cycles.


Exactly, your receiving side is not running yet.


Ok,
I am getting this now:

CODE
~$ nc --continuous --exec='mbuffer -m 1M -P 5 | sox -t flac - -t alsa plughw:0' -l -p 5555
nc: invalid option -- '-'
nc -h for help


mbuffer is there.
Go to the top of the page
+Quote Post
phofman
post Nov 5 2013, 21:09
Post #22





Group: Members
Posts: 300
Joined: 14-February 12
Member No.: 97162



Use package netcat6 instead.

Either uninstall the other netcat packages, or change alternative binary by

CODE
update-alternatives --config nc
Go to the top of the page
+Quote Post
logicom
post Nov 6 2013, 17:58
Post #23





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929



QUOTE (phofman @ Nov 5 2013, 22:09) *
Use package netcat6 instead.

Either uninstall the other netcat packages, or change alternative binary by

CODE
update-alternatives --config nc


after putting netcat6 only this is happening:

CODE
~$ nc --continuous --exec='mbuffer -m 1M -P 5 | sox -t flac - -t alsa plughw:0' -l -p 5555
in @  0.0 kB/s, out @  0.0 kB/s,  0.0 kB total, buffer   3% ful


Buffer is filling now . Is there anything like VAC for linux to try 192Khz with ?

Regards.

This post has been edited by logicom: Nov 6 2013, 18:21
Go to the top of the page
+Quote Post
logicom
post Nov 6 2013, 19:10
Post #24





Group: Members
Posts: 45
Joined: 7-November 08
Member No.: 61929




Despite of your other skills, phofman I award you with PhD in Linux smile.gif

Thank you SOOOO MUCH!

I feel happy now smile.gif

After I finish testing I will come back.

Kind Regards.
Go to the top of the page
+Quote Post
pdq
post Nov 6 2013, 20:03
Post #25





Group: Members
Posts: 3394
Joined: 1-September 05
From: SE Pennsylvania
Member No.: 24233



QUOTE (logicom @ Nov 6 2013, 14:10) *
Despite of your other skills, phofman I award you with PhD in Linux smile.gif

I hope you won't be offended if I correct your English, but I think you meant "In addition to your other skills".
Go to the top of the page
+Quote Post

3 Pages V   1 2 3 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 31st August 2014 - 01:01