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 Nov 6 2013, 21:03
Post #26





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



QUOTE (pdq @ Nov 6 2013, 20:03) *
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".


I wouldn't be offended.

Thank you.
Go to the top of the page
+Quote Post
logicom
post Nov 10 2013, 02:46
Post #27





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



Hi,

I have a problem with the playout. There is some resampling going on.
Once I play file from windows (to the same sound card) and look at the oscilloscope
everything looks fine. Once I play it from Ubuntu, It looks like it has been resampled to 48Khz.
I do not understand linux audio layers and everything looks overcomplicated to me.
I would ask you phofman once again, to help me.
Maybe telling me which distro you are using, would simplify my life, off course by following your instructions.
Basically I am stuck now.
I found some Jplay for windows, and managed to send 192Khz with foobar2000 capturing from live source and sending to asio jplay driver.
However, I did not had nice readings and I would have to do further testing.
I see that sox is a salvation for me but now alsa or pulseaudio.... I simply don't know.
иии---иии


Cheers!

This post has been edited by logicom: Nov 10 2013, 02:53
Go to the top of the page
+Quote Post
xnor
post Nov 10 2013, 03:44
Post #28





Group: Developer
Posts: 490
Joined: 29-April 11
From: Austria
Member No.: 90198



PulseAudio?
See /etc/pulse/daemon.conf options default-sample-format and default-sample-rate.
Go to the top of the page
+Quote Post
phofman
post Nov 10 2013, 10:15
Post #29





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



How did you determine your playback part was resampling? The current stream parameters entering your soundcard are listed in the virtual interface to your drivers in /proc. For device 0.0.0 that would be

CODE
cat /proc/asound/card0/pcm0p/sub0/hw_params


The alsa device specifed in sox "plughw:0" resamples only if your soundcard cannot natively play the requested samplerate. No pulseaudio is involved. PA would open (acquire) the soundcard, making it unavailable to sox. As a result sox would throw the "device busy" error message you have already encountered.

Linux audio is no black box, you just need to learn how it works. Unlike proprietary solutions which only their authors know what they actually do.
Go to the top of the page
+Quote Post
skamp
post Nov 10 2013, 10:29
Post #30





Group: Developer
Posts: 1410
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (phofman @ Nov 10 2013, 10:15) *
The current stream parameters entering your soundcard are listed in the virtual interface to your drivers in /proc.


Handy script (adevices.sh) that lists ALSA devices, what programs are using them, and with what parameters:

CODE
#!/bin/bash

if [ "$1" = '-h' -o "$1" = '--help' ]; then
me="${0##*/}"
echo "$me: list ALSA devices and relevant information."
exit 0
fi

if [ -e '/proc/asound/version' ]; then
cat '/proc/asound/version'
echo
fi

for (( i=0; i<100; i++ )); do
if [ -d "/proc/asound/card${i}" ]; then
cname="$( cat "/proc/asound/card${i}/id" )"
echo "Card ${i} (${cname}):"

for t in 'p' 'c'; do
case "$t" in
p) typeString='Playback' ;;
c) typeString='Recording' ;;
esac

for (( j=0; j<100; j++ )); do
if [ -d "/proc/asound/card${i}/pcm${j}${t}" ]; then
dname=''
if [ -e "/proc/asound/card${i}/pcm${j}${t}/info" ]; then
dname="$( grep -E '^name: ' "/proc/asound/card${i}/pcm${j}${t}/info" 2>/dev/null | cut -d ' ' -f 2- )"
fi
echo
if [ -n "$dname" ]; then
echo " * ${typeString} Device ${j} (${dname}):"
else
echo " * ${typeString} Device ${j}:"
fi
ownerPID="$( grep -E '^owner_pid' "/proc/asound/card${i}/pcm${j}${t}/sub0/status" 2>/dev/null | tr -cd '0-9' )"
if [ -n "$ownerPID" ]; then
tgid="$( grep -F 'Tgid:' "/proc/${ownerPID}/status" 2>/dev/null | tr -cd '0-9' )"
if [ -n "$tgid" ]; then
ownerPID="$tgid"
fi
ownerName="$( cat "/proc/${ownerPID}/comm" 2>/dev/null )"
echo " used by: ${ownerName} (PID ${ownerPID})"
fi
while read line; do
echo " $line"
done < "/proc/asound/card${i}/pcm${j}${t}/sub0/hw_params"
fi
done
done
echo
fi
done


Sample output:

CODE
Advanced Linux Sound Architecture Driver Version k3.11.6-1-ARCH.

Card 0 (PCH):

* Playback Device 0 (ALC663 Analog):
used by: chromium (PID 6819)
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5513
buffer_size: 16539

* Playback Device 1 (ALC663 Digital):
closed

* Recording Device 0 (ALC663 Analog):
closed

Card 1 (USB):

* Playback Device 0 (USB Audio):
used by: jackd (PID 609)
access: MMAP_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 512
buffer_size: 1536

* Recording Device 0 (USB Audio):
closed


This post has been edited by skamp: Nov 12 2013, 09:37


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
phofman
post Nov 10 2013, 10:46
Post #31





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



Very nice script, thanks!
Go to the top of the page
+Quote Post
xnor
post Nov 10 2013, 11:04
Post #32





Group: Developer
Posts: 490
Joined: 29-April 11
From: Austria
Member No.: 90198



Wasn't reading hardware info from the process filesystem deprecated like 10 years ago in favor of sysfs?

This post has been edited by xnor: Nov 10 2013, 11:04
Go to the top of the page
+Quote Post
skamp
post Nov 10 2013, 11:17
Post #33





Group: Developer
Posts: 1410
Joined: 4-May 04
From: France
Member No.: 13875



xnor, I can't find the same /proc/asound information in /sys. If I'm missing something, can you point me in the right direction?


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
phofman
post Nov 10 2013, 13:42
Post #34





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



QUOTE (xnor @ Nov 10 2013, 12:04) *
Wasn't reading hardware info from the process filesystem deprecated like 10 years ago in favor of sysfs?


Alsa drivers (even new ones) keep generating information into proc. Perhaps outdated but works very well. I understand why alsa devs would not migrate (too much other more important work to do :-) )
Go to the top of the page
+Quote Post
logicom
post Nov 11 2013, 18:13
Post #35





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



QUOTE (xnor @ Nov 10 2013, 03:44) *
PulseAudio?
See /etc/pulse/daemon.conf options default-sample-format and default-sample-rate.


CODE
resample-method = speex-float-1
; default-sample-format = s16le
; default-sample-rate = 192000
; alternate-sample-rate = 192000
; default-sample-channels = 2
; default-channel-map = front-left,front-right
Go to the top of the page
+Quote Post
logicom
post Nov 11 2013, 18:16
Post #36





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



skamp here is the output:

Advanced Linux Sound Architecture Driver Version k3.11.0-12-generic.

Card 0 (AudioPCI):

* Playback Device 0 (ES1371 DAC2/ADC):
used by: alsa-sink-ES137 (PID 1377)
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (1572864000/32768)
period_size: 441
buffer_size: 3528

* Playback Device 1 (ES1371 DAC1):
closed

* Recording Device 0 (ES1371 DAC2/ADC):
closed


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





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



QUOTE (phofman @ Nov 10 2013, 10:15) *
How did you determine your playback part was resampling? The current stream parameters entering your soundcard are listed in the virtual interface to your drivers in /proc. For device 0.0.0 that would be

CODE
cat /proc/asound/card0/pcm0p/sub0/hw_params


The alsa device specifed in sox "plughw:0" resamples only if your soundcard cannot natively play the requested samplerate. No pulseaudio is involved. PA would open (acquire) the soundcard, making it unavailable to sox. As a result sox would throw the "device busy" error message you have already encountered.

Linux audio is no black box, you just need to learn how it works. Unlike proprietary solutions which only their authors know what they actually do.


content is:

access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (1572864000/32768)
period_size: 441
buffer_size: 3528

Regards.

This post has been edited by logicom: Nov 11 2013, 18:24
Go to the top of the page
+Quote Post
skamp
post Nov 11 2013, 18:36
Post #38





Group: Developer
Posts: 1410
Joined: 4-May 04
From: France
Member No.: 13875



logicom, obviously you're supposed to run that script while playing something, i.e. while your soundcard is being used. It appears that your soundcard is set to 16 bit, 48kHz, stereo.


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
logicom
post Nov 11 2013, 18:43
Post #39





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



QUOTE (skamp @ Nov 11 2013, 18:36) *
logicom, obviously you're supposed to run that script while playing something, i.e. while your soundcard is being used. It appears that your soundcard is set to 16 bit, 48kHz, stereo.

sorry I just modified the post, please look at it.

Kind Regards.
Go to the top of the page
+Quote Post
skamp
post Nov 11 2013, 19:04
Post #40





Group: Developer
Posts: 1410
Joined: 4-May 04
From: France
Member No.: 13875



That doesn't look like the Asus Xonar D1. It looks more like the Ensoniq Audio PCI, which is very old, and only supports 48 kHz. Did you run the script on the same PC where your Xonar sound card is installed?

This post has been edited by skamp: Nov 11 2013, 19:15


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
logicom
post Nov 11 2013, 19:43
Post #41





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



QUOTE (skamp @ Nov 11 2013, 19:04) *
That doesn't look like the Asus Xonar D1. It looks more like the Ensoniq Audio PCI, which is very old, and only supports 48 kHz. Did you run the script on the same PC where your Xonar sound card is installed?


No, it is not, you are right. I will post output from xonar latter,since I am working under VMware at the moment.


This post has been edited by logicom: Nov 11 2013, 20:26
Go to the top of the page
+Quote Post
logicom
post Nov 11 2013, 20:24
Post #42





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



Here is output from real host with xonar D1:

CODE
Advanced Linux Sound Architecture Driver Version k3.11.0-12-generic.

Card 0 (D1):

* Playback Device 0 (Multichannel):
used by: alsa-sink-Multi (PID 3615)
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 88200
buffer_size: 88200

* Playback Device 1 (Digital):
closed

* Recording Device 0 (Multichannel):
closed

* Recording Device 1 (Digital):
closed


same issue...

This post has been edited by logicom: Nov 11 2013, 20:24
Go to the top of the page
+Quote Post
phofman
post Nov 11 2013, 20:53
Post #43





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



Your device is taken by pulseaudio. You have to stop pulseaudio first. The sox playback command does not use pulseaudio, you must be getting the "device busy" error.

Or pick your internal soundcard as pulseaudio default, perhaps it will release your xonar.
Go to the top of the page
+Quote Post
skamp
post Nov 11 2013, 21:05
Post #44





Group: Developer
Posts: 1410
Joined: 4-May 04
From: France
Member No.: 13875



In order to force 16/192 playback on your Xonar, I suggest putting this in /etc/asound.conf (create the file if it doesn't exist already):

CODE
defaults.pcm.rate_converter "samplerate_best"
#defaults.pcm.rate_converter "samplerate_medium"
#defaults.pcm.rate_converter "samplerate"

pcm.!default "plugXonar"
ctl.!default "plugXonar"

pcm.xonar {
    type hw
    card D1
    device 0
    format S16_LE
    rate 192000
}

ctl.xonar {
    type hw
    card D1
}

pcm.plugXonar { type plug; slave.pcm "xonar"; }
ctl.plugXonar { type hw; card D1; }


Then restart your audio apps (reboot if necessary), and set your apps to use either the 'xonar', 'plugXonar' or 'default' ALSA device, in that order, whichever works.

This post has been edited by skamp: Nov 11 2013, 21:12


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
phofman
post Nov 11 2013, 21:18
Post #45





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



I do not think that will help. Logicom's sox uses plughw:xx directly. PA uses hw:xx directly as it must communicate with the lowest buffer directly. Notice the equal buffer and period sizes. Only PA timed by HPETs can afford such setup, any other alsa application timed by soundcard interrupts needs at least two periods per buffer for proper operation.

The device is opened by PA, the only way forward is to release the device first and keep PA claws away from it. Every general desktop linux distribution user will encounter this situation as PA is a desktop standard.

https://www.google.com/search?client=ubuntu...io&start=10

http://installion.co.uk/ubuntu/saucy/main/.../uninstall.html
Go to the top of the page
+Quote Post
skamp
post Nov 11 2013, 21:32
Post #46





Group: Developer
Posts: 1410
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (phofman @ Nov 11 2013, 21:18) *
I do not think that will help. Logicom's sox uses plughw:xx directly.


It does force the bit depth and sampling rate. "plughw" alone doesn't say what parameters ALSA should use when opening the device. Without any specific instructions regarding the format, ALSA ends up using the default 48 kHz.

With that configuration, ALSA will return an error when a program tries to use the "xonar" device with anything other that 16/192 PCM; and any program that uses "plugXonar" or the default device will have its output resampled to 16/192 if it's anything different.

This post has been edited by skamp: Nov 11 2013, 21:43


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
phofman
post Nov 11 2013, 21:52
Post #47





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



It is the playback application which controls (asks for, to be correct) hwparams (i.e. rate and bitdepth, among others).

hw:X: no other but hwparams directly supported by the soundcard will be accepted . For xonar these are http://git.kernel.org/cgit/linux/kernel/gi...xygen_pcm.c#n44 .

plughw:X any hw params will be accepted and the smallest minimum conversion to fit the closest card parameters will be applied.

In logicom's case it is the parameters of incoming flac stream to sox which define the samplerate and bit depth sox will ask the plughw:xonar to accept (sox always uses the incoming file params for output file params, unless specified otherwise). If we specified the the -b32 parameter in sox output stream, we could avoid the plug plugin as xonar accepts S16_LE and S32_LE. But the samplerate will not be changed.

48kHz are default dmix values, IIRC. It is a different alsa device than logicom is using. Of course you can create a device which forces only a single samplerate/bitwidth etc. but there is no need for such setup here. Sox alone with plug plugin will pick the right samplerate/bitdepth needed.

Also, PA uses hw:X directly, avoiding any alsa setup in .asoundrc.

This post has been edited by phofman: Nov 11 2013, 21:53
Go to the top of the page
+Quote Post
logicom
post Nov 12 2013, 01:01
Post #48





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



Hi,

I completely removed pulseaudio, (I did that before as per suggestion by phofman on real host with xonar D1) and this is where I am. Playout is bad.
But before I go to shopping for a new card, or switching to debian, fedora/redhat and putting server OS,
maybe someone could help me with this,
hda
CODE
https://lkml.org/lkml/2013/1/8/549


It would be nice to experiment in virtual environment. Yet I would be able connect to the audio pin with software and measure signal characteristics... but I don't know... and knowledge is the power. I am not a jedy yet...

I will try once again all of your suggestions. In a mean time...
Thank you!

P.S. Just to mention that bitperfect transport with jplay works up to 384Khz. I play from wavelab. In addition with HIFI CABLE & ASIO BRIDGE it seems like something close to what I am looking for minus FLAC compression, anyway it is good for comparisons.
Go to the top of the page
+Quote Post
yay101
post Nov 12 2013, 02:18
Post #49





Group: Members
Posts: 7
Joined: 25-September 13
Member No.: 110355



May i ask what is wrong with using UPNP for your uses? Apart from a lack of compression (passing a wav file instead) it seems like an easy way to manage what you are after, foobar2000 + upnp output plugin -> any renderer set to directly play to your hardware. gmediarender-ressurect does a great job of this.

Or am i missing something entirely?
Go to the top of the page
+Quote Post
phofman
post Nov 12 2013, 07:05
Post #50





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



QUOTE (logicom @ Nov 12 2013, 02:01) *
I completely removed pulseaudio, (I did that before as per suggestion by phofman on real host with xonar D1) and this is where I am. Playout is bad.


What specifically do you call "bad"?

If you want to troubleshoot your setup, there are numerous ways to find out what is going on. Does the soundcard play? If your setup is just copy/paste from those lines I posted, notice sox is sending data at 48kHz 16 bits, therefore your soundcard setup would be correct. It will be what you specify there.

Basically we have not done any troubleshooting yet, that script says your device is taken by some process alsa-sink... which we do not know what is (IMO PA). Absolutely no reason to reinstall linux with some other distribution or even go shopping for a different card.

Virtual environment will not provide you with any more information than you have available (but not explored) now.

JPlay has network operation built-in. Just like jackd or network pulseaudio.
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: 24th July 2014 - 22:10