Linux Audio the way to go!?

[UnixMan]

Automatic HDCD detection/decoding + SOX resampling script for ALSA file plugin

So, here is the new script:

#! /bin/bash

# sox-resample.sh
# ---------------
# Automatic HDCD detection/decoding + SOX resampling script for ALSA file plugin
# If input rate equals maximum rate, no resampling via sox.
# (outdated info): Since sox supports only 16-bit alsa output, it pipes data to aplay for playback
# Recent versions of sox supports 24bit alsa output, so direct play via sox IS possible.

myPID="$$"
myNAME=`basename $0`

if [ $# -ne 3 ]; then
  echo -e "\nERROR: wrong number of parameters!\n"
  exit 1
fi

CHANNELS="$1"   # no. of (input stream) channels
BITS="$2"       # input stream bit-depth (word-length)
RATE="$3"       # input stream sample rate

# Configuration:
# --------------

#ALSA_DEVICE="plughw:0"
ALSA_DEVICE="hw:1"              # ALSA output device (aplay)
export AUDIODEV="plughw:1"      # sox output device (for sox direct play)

#MAX_44100=176400       # avoid "odd" rate resampling
MAX_44100=192000        # same output rate for all (avoid switching which is troublesome on my setup)
MAX_48000=192000

APLAY_DEBUG="-v"
APLAY_EXTRAS="-F 1000000"               # minimum IRQs

#SOX_DEBUG="-V3 -S"                     # show peak-level meter
#SOX_DEBUG="-V -q"                      # do not show peak-level
#SOX_DEBUG="-V3 -q --buffer 2048"       # default buffer=8192
SOX_DEBUG="-V3 -q --input-buffer 8256 --buffer 8192"
#SOX_RATE_PARAMS="-v -s"                # best resampling (?)
#SOX_RATE_PARAMS="-v -I -b 99.7 -a"     # custom resampling...
SOX_RATE_PARAMS="-v -I -a"              # custom resampling...

APLAY=`which aplay`
HDCD=`which hdcd`
SOX=`which sox`

# End of configuration
# --------------------

if [ "$RATE" == $MAX_44100 ] || [ "$RATE" == $MAX_48000 ]; then
        # already at maximum rates, no need for resampling, direct output
        OUTPUT_RATE=$RATE
else
        RESAMPLE="true"
        if [ "$RATE" == 44100 ] || [ "$RATE" == 88200 ]; then
                # 44100 family
                OUTPUT_RATE=$MAX_44100
        else
                # 48000 family
                OUTPUT_RATE=$MAX_48000
        fi
fi

echo -e "\n\nRATE=$RATE, BITS=$BITS, CHANNELS=$CHANNELS" >& 2

CDDA=""
if [ "$RATE" == 44100 ] && [ "$BITS" == 16 ] && [ "$CHANNELS" == 2 ]; then
        echo -e "Possible CDDA format detected: \nwill try to detect/decode HDCD before resampling..." >& 2
        CDDA="true"
        BITS="24"   # hdcd decoder always output 24 bit audio stream
fi

# aplay command
APLAY_CMD="$APLAY $APLAY_DEBUG -t raw -r $OUTPUT_RATE -c $CHANNELS -f S32_LE $APLAY_EXTRAS -D$ALSA_DEVICE"

# Sox resampling commands
SOX_CMD="$SOX $SOX_DEBUG -t raw -c $CHANNELS -b $BITS -r $RATE -s - -t raw -b 32 - rate $SOX_RATE_PARAMS $OUTPUT_RATE"
SOX_PLAY="$SOX $SOX_DEBUG -t raw -c $CHANNELS -b $BITS -r $RATE -s - -t alsa -b 24 rate $SOX_RATE_PARAMS $OUTPUT_RATE"

if [ -z $RESAMPLE ]; then
        # no resampling, aplay only
        PLAY_PIPELINE="cat | $APLAY_CMD"
elif [ "$CDDA" == "true" ]; then
        #PLAY_PIPELINE="hdcd -r -c | $SOX_CMD | $APLAY_CMD"
        PLAY_PIPELINE="hdcd -r -c | ${SOX_PLAY}"
else
        #PLAY_PIPELINE="$SOX_CMD | $APLAY_CMD"
        PLAY_PIPELINE="$SOX_PLAY"
fi

for ((counter=0 ; counter < 10 ; counter++ ))
do
  running_pids=`ps -C "$myNAME" -o pid=`
  other_pids=""
  for pid in $running_pids; do
    if [ "$pid" != "$myPID" ]; then
      ps -p $pid -o stat= | grep -vq "Z" && other_pids+="$pid "
    fi
  done
  #echo -e "\ntry #${counter} -- myNAME=$myNAME; myPID=$myPID; other PID(s): $other_pids" >& 2
  if [ "$other_pids" != "" ]; then
    echo -e "\nOther instance(s) still running! Waiting for PID $other_pids to terminate... (try #${counter})" >& 2
    kill $other_pids
  else
    echo "$PLAY_PIPELINE" >& 2
    eval $PLAY_PIPELINE && exit
  fi
  sleep 1
done
echo -e "\nToo many retries, abort.\n\n" >&2
exit 2

 

[UnixMan]

...and here follows the corresponding .asoundrc:

#defaults.pcm.rate_converter "lavcrate"
#defaults.pcm.rate_converter "lavcrate_higher"
#defaults.pcm.rate_converter "samplerate"
#defaults.pcm.rate_converter "samplerate_best"
#defaults.pcm.rate_converter "speexrate"
#defaults.pcm.rate_converter "speexrate_best"

############################################################################
# Give our cards some friendly aliases.

# Intel HDA analog
#
pcm.hda "default:CARD=Intel"
pcm.TV  "default:CARD=Intel"

# Intel HDA digital (S/PDIF output)
#
pcm.hdad "iec958:CARD=Intel,DEV=0"


# Julia channels 1&2 (analog & tapped I2S out)
#
pcm.Juli12 "front:CARD=Juli,DEV=0"


# Julia channels 3&4 (optical out)
#
pcm.Juli34 "iec958:CARD=Juli,DEV=0"


############################################################################
# Upsampling slaves
############################################################################

# use sox for smart/complex upsampling...
pcm.HD {
         type file
         slave {
                 pcm null
         }
         format "raw"
         file "| schedtool -a 0 -R -p 1 -e /usr/local/bin/sox-resample.sh %c %b %r"
}

pcm.HD192 {
        type plug
        slave {
                pcm "Juli12"
                format S32_LE
                channels 2
                converter "speexrate_best"
                rate 192000
        }
}

pcm.HD176 {
        type plug
        slave {
                pcm "Juli12"
                format S32_LE
                channels 2
                converter "speexrate_best"
                rate 176400
        }
}

pcm.HD96 {
        type plug
        slave {
                pcm "all"
                format S32_LE
                converter "speexrate_best"
                rate 96000
        }
}

pcm.HD88 {
        type plug
        slave {
                pcm "all"
                format S32_LE
                converter "speexrate_best"
                rate 88200
        }
}

pcm.HD48 {
        type plug
        slave {
                pcm "all"
                format S32_LE
                converter "speexrate_best"
                rate 48000
        }
}

pcm.HD44 {
        type plug
        slave {
                pcm "all"
                format S32_LE
                converter "speexrate_best"
                rate 44100
        }
}

############################################################################
# 'multi' plugin allows us to create many slave devices and then distribute
# the stream's channels between the slaves.
#
# Here we define Slave a for Julia ch 1&2 (analog & I2S) and Slave b for
# HDA S/PDIF. Then we use channel binding to send channels 0 & 1 to the
# Juli@ and channels 2 & 3 to the Intel HDA.
#
pcm.multi4 {
        type multi
        slaves.a {
                pcm "Juli12"
                channels 2
        }
        slaves.b {
                pcm "hda"
                channels 2
        }
        bindings.0.slave a
        bindings.0.channel 0
        bindings.1.slave a
        bindings.1.channel 1
        bindings.2.slave b
        bindings.2.channel 0
        bindings.3.slave b
        bindings.3.channel 1
}
# Here we define Slave a for Julia ch 1&2 (analog & I2S)
# and Slave b for 3&4 (S/PDIF).
# Then we use channel binding to send channels 0 & 1 to
# analog/I2S and channels 2 & 3 to S/PDIF.
#
pcm.multi6 {
        type multi
        slaves.a {
                pcm "Juli12"
                channels 2
        }
        slaves.b {
                pcm "Juli34"
                channels 2
        }
        slaves.c {
                pcm "hdad"
                channels 2
        }
        bindings.0.slave a
        bindings.0.channel 0
        bindings.1.slave a
        bindings.1.channel 1
        bindings.2.slave b
        bindings.2.channel 0
        bindings.3.slave b
        bindings.3.channel 1
        bindings.4.slave c
        bindings.4.channel 0
        bindings.5.slave c
        bindings.5.channel 1
}


############################################################################
# Here we are using the 'route' plugin to send the signal unchanged to a
# 6-channel device. Since the incoming stream is only 2-channel, we use
# the transfer table to copy channel 0 slave's input channel 0, channel 1
# to slave's 1, and again channel 0 to slave's 2, etc.
# The last column (1.0) is the volume, which we are leaving unchanged

# Send to Julia channels 1&2 (analog, I2S, copper S/PDIF) as well as
# to Intel HDA S/PDIF (optical) out. This can support up to 24/192 ?
#
pcm.both {
        type route
        slave {
                pcm multi4
                channels 4
        }
        ttable.0.0 1.0
        ttable.1.1 1.0
        ttable.0.2 1.0
        ttable.1.3 1.0
}

# Send to all Julia channels (analog, I2S, copper & optical S/PDIF) as
# well as to Intel HDA S/PDIF (optical) out. == Rates up to 24/96 only!
#
pcm.all {
        type route
        slave {
                pcm multi6
                channels 6
        }
        ttable.0.0 1.0
        ttable.1.1 1.0
        ttable.0.2 1.0
        ttable.1.3 1.0
        ttable.0.4 1.0
        ttable.1.5 1.0
}

############################################################################

# set default device...
#pcm.!default "TV"
#pcm.!default "HD"

(of course the relevant part is the definition of the pcm.HD "device").

 

[phofman]

The patch with clean-ups has been commited to CVS of sox. Now the CVS version supports 32bit alsa playback.

 

[phofman]

Unixman,

how about running the sox process separately from the file plugin, reading from a pipe file, and the file plugin only copies data to the pipe? If you keep the pipe open for writing by another process, sox will keep reading and will not quit when the file plugin quits writing and closes the pipe.

This works for me (just testing, no script ready):

mkfifo pipe

Reading from the pipe, feeding to sox in one shell:
cat pipe | AUDIODEV=hw:1 /usr/local/bin/sox -V -r 192000 -t raw -b24 -c2 -s - -t alsa -b 32

Keeping the pipe open in another shell:
cat > pipe

Writing to the pipe in the third shell:
cat 192-24.raw > pipe

This command can be restarted at any time. However sox keeps running, has the audio device open and plays everything it gets from the pipe. If you do not keep the pipe open in the second shell, sox quits after the third shell closes the pipe (e.g. the audio player re-opens the device when changing tracks)

 

[soundcheck]

Hi folks.

I am preparing my headless system on stick .
My goal is to have a generic setup based on UPNP. Until now I had to configure at least the nfs mount on the client which prevented from running a kind of live-cd type of OS.

I am looking for server/client software. I stepped over gmediasever and djmount for now.
djmount seems to act like a normal nfs-mount using fuse. On a first glance it sounds OK. Keeps everything flexible.

Does anybody has experience with this? Any recommendations? Any problems?

THX

 

[tbrooke]

Hi folks.

I am preparing my headless system on stick .
My goal is to have a generic setup based on UPNP. Until now I had to configure at least the nfs mount on the client which prevented from running a kind of live-cd type of OS.

I am looking for server/client software. I stepped over gmediasever and djmount for now.
djmount seems to act like a normal nfs-mount using fuse. On a first glance it sounds OK. Keeps everything flexible.

Does anybody has experience with this? Any recommendations? Any problems?

THX

What exactly are you doing? I have ben trying to figure out how to do a client server setup with spblinux, with my crossover/dsp files, as the server.

Tom

 

[java]

Buffers

What am I missing?

I have just taken a few weeks to read this thread, interesting, and informative.

BUT,

On the one hand the buffers in current CD/DVD drives and cdparanoia are undesirable, and on the other, (replay) numerous buffers do not cause problems?

Russell

 

[rossco_50]

vortexbox

Hi Soundcheck,

This is not what you were looking for, but perhaps an interesting alternative.

I have just set up a vortexbox server on an old laptop http://vortexbox.org/. Runs about 20w when in use with the screen switched off and I can shutdown and/or hibernate the server through the web interface - restart through wake on lan. It autorips any cd to the library using cdparanoia, but it automatically sets up as a nas so you can upload files from anywhere on the network.

It was one of the easiest linux set up experiences I have had so far. I have a squeezeslave client controlled through the vortexbox/squeezecenter web interface on my netbook or my phone. I think it would be quite easy to have a minimal headless and rt squeezeslave client booting from a 'stick'. John Swenson seems to have had good results with squeezeslave on the fit-pc.

Internet radio (BBC in particular) and last.fm etc is much better on this than mpd. There are even sox and brutefir setups for the server - 24bit 96hz seems to be possible but I dont have any hi-rez stuff.

Cheers,

Ross

 

[UnixMan]

On the one hand the buffers in current CD/DVD drives and cdparanoia are undesirable,

As I have already said in a previous post, the problem with audio caches in modern drives is gone. It have been solved since cdparanoia ver. 10.2

I wrote a WiKi page about "secure" CDDA extraction with Linux (also including how to use EAC on Linux with wine if you still wish to do so). Unfortunately AFAIK the WiKi is still down (?).

(replay) numerous buffers do not cause problems?

I don't wholly understand your point. Which one of the many different (sometimes antithetic) solutions proposed here do have "too many buffers" for you? What would you use / do instead to have less buffers?

BTW, the only concern I can see is about latency. But that's not a problem for normal music playback. And there are Linux solutions (e.g. "Jack") which are perfectly able to provide very little latency for MIDI, professional studio recording / mastering, etc.

Yet again, I guess that here most of us are focusing just on simple stereo playback and couldn't care less about latency.

 

[java]

As I have already said in a previous post, the problem with audio caches in modern drives is gone. It have been solved since cdparanoia ver. 10.2

I wrote a WiKi page about "secure" CDDA extraction with Linux (also including how to use EAC on Linux with wine if you still wish to do so). Unfortunately AFAIK the WiKi is still down (?).

Well, I am still seeing references to this elsewhere and here as well, reason I asked ...

Seems the good news is slow spreading ...

I don't wholly understand your point. Which one of the many different (sometimes antithetic) solutions proposed here do have "too many buffers" for you? What would you use / do instead to have less buffers?

Well basically my point is this, what is good on one side of the street is equally good the other side of the street. i.e. what is good for recording is equally good for replay, what is bad for recording is equally bad for replay ...

My point of view ....

BTW, the only concern I can see is about latency. But that's not a problem for normal music playback. And there are Linux solutions (e.g. "Jack") which are perfectly able to provide very little latency for MIDI, professional studio recording / mastering, etc.

Yet again, I guess that here most of us are focusing just on simple stereo playback and couldn't care less about latency.

Latencies only become a problem in my view, when you cannot adjust them to suit your hardware ... , i.e. all hardware is not equal at handling the same data, and the users here have a very wide range of equipment ... , not that I think this is a problem in Linux ...

My view again ...

 

[soundcheck]

Hi Soundcheck,

This is not what you were looking for, but perhaps an interesting alternative.

I have just set up a vortexbox server on an old laptop http://vortexbox.org/. Runs about 20w when in use with the screen switched off and I can shutdown and/or hibernate the server through the web interface - restart through wake on lan. It autorips any cd to the library using cdparanoia, but it automatically sets up as a nas so you can upload files from anywhere on the network.

It was one of the easiest linux set up experiences I have had so far. I have a squeezeslave client controlled through the vortexbox/squeezecenter web interface on my netbook or my phone. I think it would be quite easy to have a minimal headless and rt squeezeslave client booting from a 'stick'. John Swenson seems to have had good results with squeezeslave on the fit-pc.

Internet radio (BBC in particular) and last.fm etc is much better on this than mpd. There are even sox and brutefir setups for the server - 24bit 96hz seems to be possible but I dont have any hi-rez stuff.

Cheers,

Ross

Ross.

Cool. Didn't know about it.

THX

 

[phofman]

The Infrasonic Quartet alsa driver has been accepted to Takashi Iwai's git branch, for installation see http://article.gmane.org/gmane.linux.alsa.devel/66733 It took a few months, but the documentation from the manufacturer was far from exhaustive and the summer evenings too warm for strenuous coding

I was not able to test the external wordclock mode (1xfs, 256xfs), only slaving the card to SPDIF input. The driver sets corresponding registers specified in the documentation, it should work correctly.

 

[soundcheck]

The Infrasonic Quartet alsa driver has been accepted to Takashi Iwai's git branch, for installation see http://article.gmane.org/gmane.linux.alsa.devel/66733 It took a few months, but the documentation from the manufacturer was far from exhaustive and the summer evenings too warm for strenuous coding

I was not able to test the external wordclock mode (1xfs, 256xfs), only slaving the card to SPDIF input. The driver sets corresponding registers specified in the documentation, it should work correctly.

Great job.
Even though "Infrasonic Quartet" didn't ring a bell. Just looked it up. Seems to perform quite well. Pretty similar to ESI Juli I'd guess.

 

[GuidoR]

.... but I dont have any hi-rez stuff.

http://www.audiofilemusic.com/AnteprimaMusicDownload.asp (scroll the page up to "I brani da scaricare")
you can freely download two tracks with different resolutions:
44/16, 88/24; 176/24, (FLAC and WAV) plus lossy MP3.
Very useful for comparisons.

Guido

 

[phofman]

Great job.
Even though "Infrasonic Quartet" didn't ring a bell. Just looked it up. Seems to perform quite well. Pretty similar to ESI Juli I'd guess.

Perhaps the analog part is not up to the quality of Juli (e.g. no symmetrical outputs), but the digital part is more complex (word clock input/output), and the card offers more features (low pass filter, microphone preamp with +48V phantom power).

 

[soundcheck]

Hi folks.

Yesterday, I went to a friends place for comparing my current Linux system config and player with cics's (AA) cplay and CMP ( a widely acknowledged reference setup under XP ) on the same HW platform and very high resolution system.

Actually it was the first time for me so far that I did a "relevant" comparision to CPLAY.

Pretty exiting exercise if you read what's been said about CPLAY.

All I can say so far: Linux Audio -- The way to go! (I shouldn't forget to mention that I am not talking about an off-the-shelf Linux setup here)

More to come.

(Waiting for confirmation from the other side, since our time to listen was rather limited and I wouldn't call my judgment "neutral" enough for a final conclusion )

 

[ackcheng]

should be very exciting! Keep us posted!

 

[soundcheck]

should be very exciting! Keep us posted!

I received a phone call earlier: "NO SOUND now --- in the morning it was playing."
I was hanging on the phone all afternoon for remote support.
Everything seemed to be normal. I even managed now to log myself remotely in
and couldn't figure it out.

This is what I hate about LINUX and ALSA in particular. These instabilities, poor mixer implementations, asound.conf stuff, device handling, naming pulseaudio and especially this outdated and inconsistent documentation all over the place is driving me nuts.

Try to open up alsamixer for ESI Juli. This gets over my top. What should a beginner do with this.

No, No. It can't stay like that. If Linux wants to catch up with OSX or MS they should look at there way of handling this from a user perspective and not from a hacker perspective.

On top of this bringing in another layer which is called pulseaudio makes IMO things even worse.

Sorry for above - perhaps too much emotions in there. Above reflects IMHO the biggest issue preventing Linux from a much wider spread.

 

[1audio]

I'm sorry to see you are having such issues with Linux sound. Linux as a desktop OS is a mess, even in the commercial implementations. Too many ways to go. And Linus Torvald's recent rant about Linux bloat highlights part of the problem.

I have just set up 1 NFS server and 5 MPD players that all came up and worked flawlessly, "bit perfect" output at 24/176 on all of them. However they use ALSA connecting directly to MPD with no local UI or other stuff to cause problems. I'm using a stripped down Linux (Voyage) with just the essentials installed. More like an appliance (TiVo for example) than a general purpose computer. This has been very reliable and predictable like a Linux server would be.

Possibly the biggest problem with Linux is the constantly changing OS. Unlike Windows or OSX the Linux kernel can change almost weekly it seems. Getting a stable release that supports what you need (and Alsa at the 1.0.19 rev supported the Juli@ pretty completely) would suggest locking down the system until a rev is required because something doesn't work. The world of Linux is full of bleeding edge pieces that have not been tested together and there are no adults in the room to maintain order.

 

[soundcheck]

You need to think about it : A million hackers working in different directions or better on different islands. Think about how much redundancies this generates. How many different audio applications do we have? Think about hundreds of useless -- because almost 100% redundant -- distributions.

Why can't they join forces and produce something really good - I think the potential is there.

Let's face it -- the only real quality stuff is supplied by the industry which puts money in the bucket. ( e.g. Open-Office)

I think Ĺinux is the most inefficient - from a production perspective - undertaking in the IT world. Millions of man-hours just get burned.

Who wants to control all that. No idea.

The problem of Linux is, that it depends on certain highly ambitioned individuals. If they
leave the stage -- the show is over.
Think about it. What would happen if Linus would quit the job. I'd guess it wouldn't take long that Linux disappears. Or MS would take over.

I don't think it is sufficient to just control the kernel business. The structures
on the upper layers are not organized very well. That's at least my impression.

Ubuntu's Shuttleworth spends millions a year to get the chaos going. Why the hell don't they get audio under control. Ubuntu is having a huge role on the Gnome side. It shouldn't
be too difficult to get Alsa streamlined.

Cheers