Linux Audio the way to go!?

Status
Not open for further replies.
Jump to Latest
#843
soundcheck said:
Hi there.

I updated the MPD Wiki so that anyubuntubody can install it from sources - what I'd recommend

Some features ( e.g. 24 bit support) are nowadays (0.14-beta) available from the
source-tree snapshot only.

The snapshot runs usually pretty stable, since most of the changes are bugfixes only.

Cheers
Click to expand...

Soundcheck, thanks for the mpd wiki. Not sure why, but I am changing a nicely working HTPC to try your suggestion to use a mpd compiled from source. 🙂

Perhaps you could add git-core and automake to the requirements for compilation of mpd?
 
#844
Yep. It is related to the other thread" PC-DAc interface" here at DIY-Audio in the Digital section. I guess. Interesting to see that any of the experienced guys around still don't have a clue how to accomplish this.
Click to expand...

Log in, there are some very interesting discussions on peufeu's forum about how this can be done. However some good hardware level coding is necessary. I hope it will be done, but most of all, I hope it will be user friendly... 🙂
 
#846
SunRa said:


Log in, there are some very interesting discussions on peufeu's forum about how this can be done. However some good hardware level coding is necessary. I hope it will be done, but most of all, I hope it will be user friendly... 🙂
Click to expand...


The Beagleboard incl. I2S output, to be used as headless "stereo" streaming client seems to be very interesting. For advanced hackers only! There is even already a ported Ubuntu available.

Cheers
 
#847
I have patched the alsa file plugin to add stream parameters to the file string and to allow piping to an external command. Hopefully after a few iterations the patch will be accepted to alsa, the idea raised some interest with the alsa-lib admin.

My .asoundrc now:

Code: 
[FONT=courier new]pcm.raw {
         type file
         slave {
                 pcm null
         }
         format "raw"
	file "| /home/pavel/projects/file_plugin/resample-sox.sh %r %c %b"
	# file "| sox -V -c %c -%b -r %r -s -t raw - -t raw -4 - rate -v -s 192000 | aplay -v -t raw -r 192000 -c %c -f S32_LE -Dhw:0"

}[/FONT]

The plugin replaces %r with the actual rate, %c with the nb. of channels, %b with the nb. of bytes in the sample, and pipes the raw data to the script if the string starts with |.

The simple script:
Code: 
[FONT=courier new]#! /bin/bash
# Resampling script for file plugin, Audiotrak Prodigy192
# If input rate equals maximum rate, no resampling via sox.
# Since sox supports only 16-bit alsa output, it pipes data to aplay for playback
RATE="$1"
CHANNELS="$2"
BYTES="$3"
ALSA_DEVICE="plughw:0"
MAX_44100=176400
MAX_48000=192000
MAX_OUTPUT_BYTES=4	#e.g. ICE1724 supports 32bits natively
SOX_DEBUG="-V"
APLAY_DEBUG="-v"
APLAY_EXTRAS="-F 1000000"	# minimum IRQs
SOX_RATE_PARAMS="-v -s"	# best resampling
APLAY=/usr/bin/aplay
SOX=/usr/local/bin/sox

if [ "$RATE" == $MAX_44100 ] || [ "$RATE" == $MAX_48000 ]; then
	# already at maximum rates, no need for resampling, direct output
	BITS=$((8 * $BYTES))
	OUTPUT_RATE=$RATE
else
	RESAMPLE="true"
	BITS=$((8 * $MAX_OUTPUT_BYTES))

	if [ "$RATE" == 44100 ] || [ "$RATE" == 88200 ]; then
		# 44100 family
		OUTPUT_RATE=$MAX_44100
	else
		# 48000 family
		OUTPUT_RATE=$MAX_48000
	fi
fi

APLAY_CMD="$APLAY $APLAY_DEBUG -t raw -r $OUTPUT_RATE -c $CHANNELS -f S${BITS}_LE $APLAY_EXTRAS -D$ALSA_DEVICE"
# echo "$APLAY_CMD"

if [ -z $RESAMPLE ]; then
	# no resampling, aplay only
	cat | $APLAY_CMD
else
	# resampling
	SOX_CMD="$SOX $SOX_DEBUG -t raw -c $CHANNELS -s -$BYTES -r $RATE - -t raw -$MAX_OUTPUT_BYTES - rate $SOX_RATE_PARAMS $OUTPUT_RATE"
#	echo "$SOX_CMD"
	$SOX_CMD | $APLAY_CMD
fi[/FONT]

The best resampling algorithm of sox 14.2.0 (-v -s) consumes over 30% of my ancient Duron 1GHz 64kB cache for 44.1 wav and xruns occur sometimes when working in X. There are several ways to avoid the xruns (more CPU power, playing with the script - renicing and/or real-time scheduling of sox using sudo, etc.)

Of course the overall playback latency is huge, but that is something audiophiles do not have to care about.
 
#850
BTW:

I am runnng at close to 50% CPU load if running SRRC in best sinc within MPD.
Best would be to have the GPUs running these kind of jobs (e.g. CUDA)
koon@ koonlab.com is doing this quite succesfully.

Did you play with Jack & SOX? Perhaps it is worth to think about Jack/Netjack
implementation of the whole stuff.

Newest thing on my scope:

I am just looking at the options I'd have using a Beagleboard with I2S out into any kind of I2S DAC ( my SABRE, 1534 or TAS5706).

A Jack (netjack) setup might be approriate . Might be a great option to get rid of USB/FW/PCI and at the same time getting away with realtime audio from the main server machine.

Cheers
 
#851
Well, I kind of do not see the advantage of jack for the fixed-chain audiophile playback, apart of the network communication and support from some applications.

Can you put resampling into the jack chain? I think all sources/sinks run at the same fs. Another issue is switching source fs - jack must be restarted with new params, IIRC.

If the chain must be restarted when changing fs anyway, then the network transport for the non-jack chain can be provided by simple netcat (with a higher latency, of course).
 
#852
phofman said:
Well, I kind of do not see the advantage of jack for the fixed-chain audiophile playback, apart of the network communication and support from some applications.
Click to expand...
Well, if by 'audiophile playback' you mean simply delivering bits from a sound source to the sound card untouched and unaltered, then I'd agree that Jack adds little value to that process.

Of course, IMHO this misses 50% of the value of PC playback, but that's another discussion.


Can you put resampling into the jack chain? I think all sources/sinks run at the same fs. Another issue is switching source fs - jack must be restarted with new params, IIRC.
Click to expand...
The Jack 'graph' always runs at a fixed sample rate. Changing the rate requires a restart of jackd and all clients. If resampling is necessary, it would have to be done by the client; as far as I know, none of the drivers support resampling in any way. (unless you use something like a resampling plug interface in alsa)


If the chain must be restarted when changing fs anyway, then the network transport for the non-jack chain can be provided by simple netcat (with a higher latency, of course).
Click to expand...

I've started playing around with NetJack2, and while I've gotten it to mostly work it's been rather delicate. I've been using a Windows box as the master though, which may be part of the problem. Even so, it appears that my Core2Duo slave machine misses packets on occasion despite both the machine and network being basically idle, and only using 2 channel/44.1 audio; this indicates that with NetJack it may still be necessary for the slave machine to have low latency/RT behavior, even though it's not running the soundcard. I'll caveat this by saying that there is a 'slow' mode available that inserts an extra buffer/cycle delay in the processing, but so far the Windows master has freaked out every time I've tried starting the slave in slow mode. I'm still investigating that.
I also plan to try a dedicated network interface - my setup pulls the audio from an smb share over the same network that NetJack is using, which may be part of the problem.

So, I'm still hopeful that the quirks can be worked out, but given that we really don't care about latency as such, it's entirely possible that another network transport mechanism would work better if all you care about is 2-channel. Unfortunately, if you want to do multichannel, I'm not aware of anything that will provide the functionality of NetJack.
 
#853
Oh - BTW in my netjack config I tried using jconv for the first time instead of BruteFir. jconv looks promising. I don't think it has all the advanced routing capabilities of BruteFir, but if all you do is straight filtering of input to output it looks good. It uses a variable partition size to allow much lower latency without expanding the cpu requriements. A 2 channel convolution with 64k taps used 3% or less of the cpu on my C2D E6300 (1.8GHz I think - the slowest of the original C2D chips)
 
#854
dwk123:
I guessed it'd be a bit tricky. I read also somewhere that you need to be very careful
with your ethernet setup. E.g. 1GB/s to 100MBit/s can cause already trouble. I think key
is to get the network harmonized first. Either you go for all 1GB or all 100Mb.

However Squezzebox and similar seem to be able to manage the stream properly.
Of course this won't be a low latency realtime approach as done with Jack.

Cheers
 
#855
dwk123 said:

Well, if by 'audiophile playback' you mean simply delivering bits from a sound source to the sound card untouched and unaltered, then I'd agree that Jack adds little value to that process.

Of course, IMHO this misses 50% of the value of PC playback, but that's another discussion.
Click to expand...

What specifically is that 50% missed value of PC playback? I always point out I am talking about quality playback, not recording/mastering/playing midi instruments where latency is of major importance.


dwk123 said:
The Jack 'graph' always runs at a fixed sample rate. Changing the rate requires a restart of jackd and all clients. If resampling is necessary, it would have to be done by the client; as far as I know, none of the drivers support resampling in any way. (unless you use something like a resampling plug interface in alsa)
[/B]
Click to expand...
And that is exactly the reason I do not see jack useful for extreme audiophile (basically almost insane) setup with SW upsampling to circumvent/minimize upsampling steps in the DAC chips. I want to play a mixed fs content without the hassle of restarting the whole chain. I know the session management via Lash would help a great deal, still why making things complicated without any benefits.

dwk123 said:
I've started playing around with NetJack2, and while I've gotten it to mostly work it's been rather delicate. I've been using a Windows box as the master though, which may be part of the problem. Even so, it appears that my Core2Duo slave machine misses packets on occasion despite both the machine and network being basically idle, and only using 2 channel/44.1 audio; this indicates that with NetJack it may still be necessary for the slave machine to have low latency/RT behavior, even though it's not running the soundcard. I'll caveat this by saying that there is a 'slow' mode available that inserts an extra buffer/cycle delay in the processing, but so far the Windows master has freaked out every time I've tried starting the slave in slow mode. I'm still investigating that.
I also plan to try a dedicated network interface - my setup pulls the audio from an smb share over the same network that NetJack is using, which may be part of the problem.
[/B]
Click to expand...


SImple netcat will suffice, unless you want to be compatible with windows

I just did some tests with the patched file plugin. Just changing the script allows for network playback easily:

Code: 
 #! /bin/bash
# Resampling script for file plugin, Audiotrak Prodigy192
# output via netcat

RATE="$1"
CHANNELS="$2"
BYTES="$3"


MAX_44100=176400
MAX_48000=192000
MAX_OUTPUT_BYTES=3	#e.g. no need to transfer more than 24bits over network

SOX_DEBUG="-V"

SOX_RATE_PARAMS="-v -s"	# best resampling
SOX=/usr/local/bin/sox
NETCAT=/bin/netcat

PLAYBACK_HOST=soundmachine.mydomainhome.cz
PLAYBACK_PORT_44100=44100
PLAYBACK_PORT_48000=48000

BITS=$((8 * $MAX_OUTPUT_BYTES))

if [ "$RATE" == 44100 ] || [ "$RATE" == 88200 ] || [ "$RATE" == 176400 ]; then
	# 44100 family
	OUTPUT_RATE=$MAX_44100
	PLAYBACK_PORT=$PLAYBACK_PORT_44100
else
	# 48000 family
	OUTPUT_RATE=$MAX_48000
	PLAYBACK_PORT=$PLAYBACK_PORT_48000
fi

NETCAT_CMD="$NETCAT -q1 $PLAYBACK_HOST $PLAYBACK_PORT"

SOX_CMD="$SOX $SOX_DEBUG -t raw -c $CHANNELS -s -$BYTES -r $RATE - -t raw -$MAX_OUTPUT_BYTES - rate $SOX_RATE_PARAMS $OUTPUT_RATE"
$SOX_CMD | $NETCAT_CMD

Each fs family has a dedicated port, where netcat listens and runs aplay when connection occurs:

Code: 
while true; do netcat -l -p 48000 -c 'aplay -v -Dplughw:0 -F 1000000 -t raw -c 2 -f S24_3LE -r 192000'; done

while true; do netcat -l -p 44100 -c 'aplay -v -Dplughw:0 -F 1000000 -t raw -c 2 -f S24_3LE -r 176400'; done

Works OK.

This is for stereo. I checked 6 channels 176400 over network (just changed -c 6 -Dplug:surround51 in aplay). The playback produces 25Mbps network flow.My weak Duron 1GHz (the recipeint side) kept throwing xruns whenever I switched windows in X. However, simple renicing to -19 fixed it and I did not experience any xruns afterwards. Played over regular 100Mbps, built-in switch of my wifi router.
Code: 
 while true; do sudo nice -n -19 netcat -l -p 44100 -c 'aplay -v -Dplug:surround51 -F 1000000 -t raw -c 6 -f S24_3LE -r 176400'; done

Using this technology takes the least requirements on the HW, and if low latency is not required, I think it can be the way to go.
 
#857
intel motherboard ADAT output ?

I am trying to see if the HCIx intel HDaudio controller (some intel VIIV motherboards have ADAT output) has the ADAT feature also supported by Linux ALSA.

www.xpmediacentre.com.au/community/...at-8-channels-digital-uncompressed-audio.html


That would be a very simple and quite clean way to get 8 optically isolated channels out of the PC to a DIY board around Wavefront OPTOREC then to multichannel DACs.
The receiver board around the optorec chip would the only thing to do ourselves and that seems very simple (an application schematic is shown in datasheet).
The optorec chip is really a nice and esay to use chip (can generate clock with enough drive for 4 dacs).

If some of you have answers... you are welcome
 
#859
Hi folks.

I just had a look at ecasound again. I think I mentioned this great tool some time ago.
Ecasound is probably the best performing tool for recording in realtime.

I just figured - again - It also sounds great on playback. I can use it with my EMU USB 0404 on HD material in 96/24 (which doesn't work with brutefir and EMU- the alsa output to plug seems to have a flaw) .

I converted the flacs ( flac -d file) to wav and played them from RAM (/dev/shm)

ecasound you can install from the Ubuntu repositories in 10 seconds:

sudo apt-get install ecasound

Then you just run e.g.

ecasound -f:24,2,96000 -B:rt -b:32 -r:80 -i playfile.wav -o alsaplugin,1,0

Let me know what you think!

Have a look at the man pages. You can do a lot of nice stuff with ecasound. Especially if
you look into measurements etc.



Cheers
 
Status
Not open for further replies.
Top Bottom