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.

[snip]


If plughw: plays a file when hw: doesn't it tells you the numbers
after the "hw:" are correct, but that the file isn't a format that the
device can accept without changes.

Yes.

pi@raspberrypi:~ $ aplay -Dhw:1,0,0 xxx.wav Playing WAVE 'xxx.wav' :
Signed 16 bit Little Endian, Rate 44100 Hz, Stereo aplay:
set_params:1233: Sample format non available Available formats: - S24_3LE

plughw plays

catting the hw_params file will tell you what is actually being
accepted when plughw: plays.

pi@raspberrypi:~ $ cat /proc/asound/C1/pcm0p/sub0/hw_params access:
MMAP_INTERLEAVED format: S24_3LE subformat: STD channels: 2 rate: 44100
(44100/1) period_size: 5513 buffer_size: 22050


It's being read as 2-byte samples and they're padded out to 3 bytes
before sending ? It needs a 16bit format ? Or am I barking, and up the
wrong tree ?

The above implies the device does have a name string 'C1' btw.

The above confirms 44.1k is being sent. So if you heard the result the DAC
was playing the 44.1k. Although the actual rate may not be *exactly* 44.1k
as judged by the DAC.

The S24_3LE tells you that the DAC is taking three bytes per sample to
accept the values. It may not be willing to accept two bytes per sample.

This sort of behaviour is quote common for sound hardware. It means that
when you want to play 16 bit material a 'third byte' has to be tacked onto
each two-byte sample when it is passed to the sound hardware.

i.e. The values are 'padded', usually with zero-value bytes. So whatever
player you use has to either do this, or ask something like ALSA to do it
along the way.

If your choice of playing software can let you select the output device,
you can then choose to tell it to use 'plughw:1,0,0'. If this produces
music, you can use cat the hw_params to see that the rate is correct. If it
is, you're probably getting the playout with only the necessary 'padding'
when playing 16bit files.

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.

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!

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