Jim Lesurf said:
In article ,
Richard Robinson wrote:
Jim Lesurf said:
In article ,
Richard Robinson wrote:
... $ cat /proc/asound/C1/pcm0p/sub0/hw_params access: RW_INTERLEAVED
format: S24_3LE subformat: STD channels: 2 rate: 44100 (44100/1)
period_size: 5513 buffer_size: 22050

OK. That shows that what is being sent is 44/1k stereo, 24bit carried
as 3 bytes per sample in LE order (like Wave files). That may mean it
is Audio Class 1. Class 2 tends to use four bytes per transferred
value. It *should* be lighting any rate leds on the device for 44.1k.
If it doesn't there may be a timing problem or something else.

If I play a 48k wav, the indicator lights up on the DAC. For a 44.1k
file, it doesn't.

That is curious. If you still hear something and catting confirms it is
44.1k it seems the DAC indicator isn't recognising the rate whist the DAC
is happy to play it. I've seen this in cases where a rate wasn't close
enough to what the DAC expected. But I don't know if that means your
computer clock is 'off' or that the DAC's idea of 44.1k is 'off'. However
the problem is probably with the way the DAC detects the rate.

I also have a desktop machine, connected to the DAC via S/PDIF. From there,
"aplay -D hw:" works, and catting /proc/asound/whatnottery says the format
is S16_LE. Again, 48k wavs light the appropriate LED on the DAC, 44.1k wavs
don't.

My real-world music being all flac or mp3, I also tried alsaplayer. Same
information except that the DAC LED then doesn't recognise either sampling
rate.

And I think this becomes a matter of intellectual curiosity rather than
practicalities - [please correct me if I'm wrong, but ...] I can't see that
the byte-padding is any kind of issue, it makes no difference to the meaning
of the data and the processing overhead isn't to worry about. The timing
question may be more of an issue; I'd be inclined to think that a
purpose-built Cambridge Audio gadget is more likely to be doing the right
thing than a raspberry pi / old generic destop machine, and I could check
this by switching gadgetry round, run the DAC off the laptop instead and see
if it makes any difference, but ... well, basically my ears are 60+ years
old and I'm delighted with what I'm hearing already. It'll do.

But it's led me to realise how much I don't know, both about linux sound s/w
in particular and digital audio in general ...

So far as possible ALSA is designed to avoid any needless 'conversions'.
using 'hw:' essentially forbits any conversions or changes. Using 'plughw:'
allows 'necessary' conversions. This is convenient but opens the risk of a
change being made that wasn't actually necessary.

.... one thing I realise I'm not clear on is, what's actually being sent down
the cable into the DAC. Talk of byte-padding suggests that the compressions
(flac/mp3) are unpacked in the alsa layer, or higher, and the DAC receives
raw samples ? But the DAC itself supports these formats, so is there still
some unnecessary conversion going on ?

You should also find that you can use aplay with 'hw:' to play 24bit files
as these need no added bytes.

A potential snag with some desktop audio playing programs is that they may
do odd things of their own. e.g. a version of Audacious I used in the past
always truncated 24bit wave files to play as 16bit, even though it then
duly added padding so the result 'looked like' 24bit to a cat of hw_params.
I was only able to confirm this by making a digital capture of the output
stream. 24bit flac files, however, were *not* truncated. I guess the
developers only tested with flac files!

So if someone tells you that 'flac files sound better/worse than wave
files' or similar, this might be the real reason. The problem is that it
can be a bit of a faff about to check!

Yes. I'm not much of a hardware person, either. I now have half-a-zillion
different ways of playing the files, all of them faintly cranky from some
viewpoint or other; at least they're non-destructive. I've also got involved
in a recording project that's pushing me to learn how to drive audacity, I
might want to be sure that files I work on there aren't losing any quality.
*sigh* Inputs could be a whole other mess, I'm not sure how far I want to
take that ...


Thanks for your help. Yesterday evening, I actually used the system as
intended, for the first time - sat in a comfy chair with a laptop on my knee
& no wires attached, and listened to whatever I wanted with no hassle.

And mpd's auto-update makes it a very easy way to sort out tagging, which
was a huge bonus.


--
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem

My email address is at http://www.qualmograph.org.uk/contact.html