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.


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

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.

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:

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

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

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:
...
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've just had a quick read of
http://www.audiomisc.co.uk/Linux/ALSA/ALSAforUsers.html

and it looks like just what I was needing (including answering my question
about alsa names) ... I'll investigate later & see what happens. Thanks.


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

Jim Lesurf said:

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.

Okay. With the help of your page + a bit of rejigging, it's getting close. I
realised I also needed a sound editor, so the sound files now live on a hard
disk plugged into the backend raspberrys; and alsa now recognises the DAC as
default, mpd plays, audacity sees the DAC directly and plays, all the other
usual players seem to find alsa and play, even amarok, which I was nervous
of.

Except that there is something up with samplerates, I'll follow that up to your
other post, later.


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

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