Hi,

I've been experimenting with using a couple of USB sound devices and have
encountered various 'odd results' in the process. I've tried asking in
other places to approach this from the 'computer' angle. But as yet not
really had useful responses from that. So I though it was time I asked here
to see if I got a more knowledgeable response. :-)

To keep it brief I can summarise as follows.

I'm currently using a Halide Bridge USB-SPDIF 'convertor'. Playing this
into a DAC and also able to record the digital output for examination. I'm
playing LPCM wave files with various bit rates, some 16bit, some 24bit.
Using two Linux boxes - one Ubuntu the other Xubuntu. Main results that
matter here a

1) I've put what seems the appropriate details into my 'asoundrc' file to
define the Bridge as the default output device. If I play a wave file with
the basic ALSA 'aplay filename' command then what emerges from the bridge
is the correct series of values at the correct rate. This is so for
96k/24bit files as well as lower rates and 16bit. Hence so far as I can
tell, my ALSA setup and hardware and the Bridge all work OK.

but...

2) If I use the 'AlsaPlayer' player it works for 44.1k/48k files, but
refuses to accept higher sample rates as 'out of range'. I've looked at the
sources for AlsaPlayer (from alsaplayer.org) and can find the 'trap' that
does this in the 'app/Main.cpp' file. But I don't know enough about the
rest of the code to tell if changing this would fix the problem *if* I knew
enough to then compile it correctly without getting into a mess.

If anyone reading this has rather better C/C++ skills than myself is
willing to look at the code and say more, I'd welcome that. I've emailed
the person maintaining the site, but I'm not sure if they can help given
what they say themselves on the site!

3) If I use Audacious it 'seems to work' in the sense that it will play
files up to 96k/24bit and I hear the results. The output sample rate
follows the source material as does 'aplay'. However if I record the spdif
output I find that the lowest byte of 24bit material is lost. i.e. the
output just conveys the top 16bits. This is despite my having set the
options in Audacious for '24bit' 'alsa output' and 'avoid processing'.

Has anyone else managed to get Audacious to measurably output 24bit values
at 96k? If so, any idea what is going wrong with (3)? Given (1) it doesn't
seem to be an inherent problem with my systems.

I've tried two other players with different - also unsatisfactory -
results. So far AlsaPlayer and Audacious seem 'best'. I'd like to avoid
having to try every expletive player app in turn when it would probably
make more sense to fix one of the above and understand the cause of the
problems!

In normal use I generally play 44.1/48k 16bit material so the above aren't
problems for day-to-day use, and I can happily use AlsaPlayer or Audacious
as I choose.

But (3) is clearly odd given that Audacious gives the option for '24 bit
output', and it does cramp testing and evaluation to only use the 'aplay'
command for tests. The way things are going I'll end up writing my own lpcm
player app! I'd have thought that was the last thing the world should need
give how many already exist... but which may not actually do all that is
needed under the hood! :-)

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html