Jim Lesurf said:
In article ,
Richard Robinson wrote:
Jim Lesurf said:
In article ,
Richard Robinson wrote:

Hello. I'm baffled and looking for help. I've been trying to play
audio over my home wifi
... But if you want audio quality you might find you prefer using ALSA.

aplay -L

will list playout devices. I'd hope your system can then find the
required device. Usually Pulse will send out via ALSA anyway.

Thanks, but ... I _think_ I've ended up telling alsa to go out via
pulse. I do not like configuring linux sound. I never have, and it
doesn't seem to have got any more comprehensible since the last time I
looked ... I seem to have something that works and that'll do for now. I
may find more tuits for it later.

OK, that's fine if it is working correctly. Although I suspect in practice
Pulse is actually then sending out via ALSA as it tends to sit 'on top' of
it. If you want quality, though, check that the output sample rate reaching
the *playing hardware* is following the rate of the source material. Pulse
has a habit of mangling everything into 48k sample rate.

TBH setting up ALSA is usually pretty simply for playout. The problem is
generally the lack of documentation. But for future reference there are
pages on my Audiomisc site that explain how to set up ALSA for quality
audio replay. The hardest bit can be stopping Pulse from then 'nannying'
you and changing what you set.

I have had trouble with ALSA/Pulse (I've never got on with linux audio
backends, it's one of my least favourite things about it). I've been
fiddling intermittently with this for a while and not getting it right, it's
likely I've got some odd configurations hanging around as a result. Pulse
insisted on coming into the mix because it seemed to offer the possibility
of doing what I first thought of, pushing audio from the client machine. Now
I see that that doesn't work, I'd probably do best to wipe the raspberry and
set it up again from a clean start; at which point I'll bear that in mind.

Thanks.

The DAC has a little row of lights showing the incoming sample rate. I just
set something playing and had a look ... none of them are lit up. Helpful,
no ? :-/


--
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

In article ,
Richard
Robinson wrote:

The DAC has a little row of lights showing the incoming sample rate. I
just set something playing and had a look ... none of them are lit up.
Helpful, no ? :-/

Afraid I've forgotten what kind of DAC you're using, so can only guess.

However it is possible that the DAC is fussy about the rate. So if the
playout is running too fast or too slow (or is too erratic) the LED doesn't
light up.

You can read a 'file' for each device and - when audio is playing - the
relevant one will state the rate, etc, being sent out to hardware. My
memory being what it is I can't immediately recall the 'file' names for
this. But if no-one else can say I'll find out and let you know later on.
[ Edit: see below :-) ]

If you're using -aplay you can use this to probe what works

get a list of devices from 'aplay -l'

then try 'aplay -D hw:one of them file.wav' to see if that will
play the file and give you a coconut. Using 'hw:' tells -aplay
to *not* provide any conversions. So it will only play when the
device can accept the rate and bit-depth of the wave file.

You can use sox to generate versions of a wave file with various
rates and bit depths.


Edit: Found how to check the output in my notebooks

look at files like /proc/asound/cardn/pcmmp/subp/hw_params

and cat their content to see what they hold *while you play
some audio*. Each file will report what's happening for a given
card, etc. If you hear music, the relevant one will report the
rate that is being used.

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

Jim Lesurf said:
In article ,
Richard Robinson wrote:

The DAC has a little row of lights showing the incoming sample rate. I
just set something playing and had a look ... none of them are lit up.
Helpful, no ? :-/

Afraid I've forgotten what kind of DAC you're using, so can only guess.

I think I probably didn't mention it ?

However it is possible that the DAC is fussy about the rate. So if the
playout is running too fast or too slow (or is too erratic) the LED doesn't
light up.

You can read a 'file' for each device and - when audio is playing - the
relevant one will state the rate, etc, being sent out to hardware. My
memory being what it is I can't immediately recall the 'file' names for
this. But if no-one else can say I'll find out and let you know later on.
[ Edit: see below :-) ]

Thanks, yes

$ 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


If you're using -aplay you can use this to probe what works

get a list of devices from 'aplay -l'

then try 'aplay -D hw:one of them file.wav' to see if that will
play the file and give you a coconut. Using 'hw:' tells -aplay
to *not* provide any conversions. So it will only play when the
device can accept the rate and bit-depth of the wave file.

I'm confused about the names :-
aplay -l gives
card 1: C1 [Cambridge Audio DAC100 USB 1], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
but none of the obvious (to me, anyway) names from that produce anything
audible. What should I be using for a name ?




--
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

In article , Richard
Robinson wrote:
Jim Lesurf said:
In article ,
Richard Robinson wrote:

The DAC has a little row of lights showing the incoming sample rate.
I just set something playing and had a look ... none of them are lit
up. Helpful, no ? :-/

Afraid I've forgotten what kind of DAC you're using, so can only guess.

I think I probably didn't mention it ?

However it is possible that the DAC is fussy about the rate. So if the
playout is running too fast or too slow (or is too erratic) the LED
doesn't light up.

You can read a 'file' for each device and - when audio is playing -
the relevant one will state the rate, etc, being sent out to hardware.
My memory being what it is I can't immediately recall the 'file' names
for this. But if no-one else can say I'll find out and let you know
later on. [ Edit: see below :-) ]

Thanks, yes

$ 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 you're using -aplay you can use this to probe what works

get a list of devices from 'aplay -l'

then try 'aplay -D hw:one of them file.wav' to see if that will play
the file and give you a coconut. Using 'hw:' tells -aplay to *not*
provide any conversions. So it will only play when the device can
accept the rate and bit-depth of the wave file.

I'm confused about the names :- aplay -l gives card 1: C1 [Cambridge
Audio DAC100 USB 1], device 0: USB Audio [USB Audio] Subdevices: 0/1
Subdevice #0: subdevice #0 but none of the obvious (to me, anyway)
names from that produce anything audible. What should I be using for a
name ?

Try

aplay -L

i.e. upper case 'L' as that gives more info than lower case 'l'.

It's usually easier when experimenting to use the ALSA numbers. So use
aplay with something like

aplay -D hw:1,0,0 filename.wav

Note that when using "hw" the file may need to be 24bit to match the
harware requirement. To check with other files you can use

aplay -D plughw:1,0,0 filename.wav

Note that

aplay -D hw:1

means the same as assuming the same as hw:1,0,0, so you may find you only
need hw:1 rather than filling in the following zeros.

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.

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

There are alternative syntaxes like

-D hw:B20

or

-D hw:CARD=USB,DEV=0

which may work for particular devices as these are their name strings or
are recognised. However the strings I've quoted above are for devices I
have.

In your case I guess it might be that

-D hw:C1

works. But you'd need to experiment.

The card/device/subdevice numbers are assigned by ALSA at bootup. So may
change if you alter the hardware arrangements. But they are easier to find
and use if you aren't changing anything. The name strings will 'follow the
device' if you re-arrange the hardware, but a different device may have a
different name string.

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

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.

It's usually easier when experimenting to use the ALSA numbers. So use
aplay with something like

aplay -D hw:1,0,0 filename.wav

Note that when using "hw" the file may need to be 24bit to match the
harware requirement. To check with other files you can use

aplay -D plughw:1,0,0 filename.wav

Note that

aplay -D hw:1

means the same as assuming the same as hw:1,0,0, so you may find you only
need hw:1 rather than filling in the following zeros.

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 ?


--
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

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

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

Huge said:
On 2016-07-01, Richard Robinson wrote:
Jim Lesurf said:
In article ,

[47 lines snipped]

How done with it and buy a Squeezebox or two on eBay. Like wot I did.

Squeezebox ? Nah, clarinet's my instrument.

[ ;-) ]


--
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