Audio over wifi
 

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

Audio over wifi
 

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

Audio over wifi
 

In article ,
Richard
Robinson wrote:
Jim Lesurf said:
[snip]

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.

Yes. In itself, byte padding doesn't matter. So on that score using
'plughw:' or an equivalent is harmless. The snag is that 'plughw:' allows
"any necessary conversions" so there is a risk some other conversion
happens because the system decided it was "necessary". But you can check
this by catting the hw_params.



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

Chances are that the DAC only understands plain LPCM (usuallly little-end
order as in a wave file.) Any other type of file you play will need to be
coverted into LPCM by the playing software or some other 'intermediary'
layer of software. This will depend on your choice of playing software.

But, yes, flac or mp3 will have to be being turned into LPCM before is goes
though ALSA to the hardware.


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

Well, you can use '-arecord'. This is the ALSA command that can be used to
capture audio from devices in the same way as '-aplay' lets you play audio.

If nothing else, that will let you check what is happening. It represents
the simplest and most basic way to record and just uses ALSA. So no other
software need get in the way. (You can also use 'sox' to play and record
and it will do format conversions as it does so.)

FWIW I've written a basic sound recording program for Linux which uses ALSA
and *only* pads with bytes where needed. It also gives a 'PPM' display so
you can monitor the levels. The program, with source code, is linked from
the software page on my Audiomisc website. I wrote this program
specifically to ensure that the program was one I knew would *not* fiddle
about with the values. Note that as it stands it assumes you will use a USB
audio device. But that could be changed if you require.

The above program is what I use to make audio recordings.

(There are also some other programs like a sig gen and scope/FFT analyser
so you can do tests.)

If you use Audacity it may convert. e.g. I think it tends to turn
everything into 32 bit floats internally. But you should be able to set it
to use 'hw:' or 'plughw', and in my own tests it seems to preserve 24 bit
recodings with bit-accuracy. So it should be OK if used with care.

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

Audio over wifi
 

Jim Lesurf said:
In article ,
Richard Robinson wrote:
Jim Lesurf said:
[snip]
And I think this becomes a matter of intellectual curiosity ...
Yes. In itself, byte padding doesn't matter. ...

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

Chances are that the DAC only understands plain LPCM (usuallly little-end
order as in a wave file.) Any other type of file you play will need to be
coverted into LPCM by the playing software or some other 'intermediary'
layer of software. This will depend on your choice of playing software.

But, yes, flac or mp3 will have to be being turned into LPCM before is goes
though ALSA to the hardware.

Having now had another reread of The Manual, I think what I was missing is
that it talks about "Digital inputs" (S/PDIF, TOSlink) and "USB in" in
separate sections. So it doesn't regard USB as digital info, it expects the
raw bytestream ? Okay, I can wrap my head round that, now I've noticed it.

I also toggled the DAC into Class 2 Audio mode, with no discernible effect
on the bitrate LED (there may be more to do here wrt s/w support, and maybe
cabling).

I now have half-a-zillion different ways of playing the files, all of
them faintly cranky from some viewpoint or other.

I think I want to try a clean reinstall of the raspberry, see how far I can
get before something drags in complications like pulse.


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

Well, you can use '-arecord'. This is the ALSA command that can be used to
capture audio from devices in the same way as '-aplay' lets you play audio.

If nothing else, that will let you check what is happening. It represents
the simplest and most basic way to record and just uses ALSA. So no other
software need get in the way. (You can also use 'sox' to play and record
and it will do format conversions as it does so.)

FWIW I've written a basic sound recording program for Linux which uses ALSA
and *only* pads with bytes where needed. It also gives a 'PPM' display so
you can monitor the levels. The program, with source code, is linked from
the software page on my Audiomisc website. I wrote this program
specifically to ensure that the program was one I knew would *not* fiddle
about with the values. Note that as it stands it assumes you will use a USB
audio device. But that could be changed if you require.

The above program is what I use to make audio recordings.

I want to record what I sound like against a couple of mono tracks recorded
alsewhere; Audacity looks like the easiest bet.

(There are also some other programs like a sig gen and scope/FFT analyser
so you can do tests.)

If you use Audacity it may convert. e.g. I think it tends to turn
everything into 32 bit floats internally. But you should be able to set it
to use 'hw:' or 'plughw', and in my own tests it seems to preserve 24 bit
recodings with bit-accuracy. So it should be OK if used with care.

It seems fairly civilised, in the sense that the devices it offers are the
ALSA names (I'm still not sure what my problem was there, but it seems to
have gone away), so at least I know what it's doing wrt i/o.

But this is currently a hardware issue - the only mic I can find is an old
AKG dynamic, which isn't what the headphone/mic socket on a laptop likes; v.
low signal, hideously infeasible hiss (I used to have a more suitable one,
but idiotically I put it away with a battery in and now the contacts are
corroded. I'm a fool). Yes, USB would probably be the way to go; the friend
I'm doing the recording with has offered to lend me an "interface"; from
which I expect to learn /something/.

But this gets clunky over rdesktop on the raspberry pi, I'm back to a USB
cable trailing across the floor from a laptop ...and fighting off thoughts
of installing something bigger and more complicated than audacity. ardour ?
Gaah ... *grin*.

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

Audio over wifi
 

In article ,
Richard
Robinson wrote:
Jim Lesurf said:


Having now had another reread of The Manual, I think what I was missing
is that it talks about "Digital inputs" (S/PDIF, TOSlink) and "USB in"
in separate sections. So it doesn't regard USB as digital info, it
expects the raw bytestream ?

They are all examples of byte streams. But the way the operate is
different. The spdif / toslink have the 'sender' just send the bytes or
bits without any awareness of what might be at the 'receiving' end of the
cable.

The USB connection 'negotiates' back and forth to 'handshake' the exchanges
as a series of batches of data. Various methods are used for this, some
better than others.


I also toggled the DAC into Class 2 Audio mode, with no discernible
effect on the bitrate LED (there may be more to do here wrt s/w support,
and maybe cabling).

Class 2 may be 4 bytes per sample whilst Class 1 may just use 3. The
differences are in the protocols and methods for the 'negotiations' etc.



But this is currently a hardware issue - the only mic I can find is an
old AKG dynamic, which isn't what the headphone/mic socket on a laptop
likes; v. low signal, hideously infeasible hiss (I used to have a more
suitable one, but idiotically I put it away with a battery in and now
the contacts are corroded. I'm a fool). Yes, USB would probably be the
way to go; the friend I'm doing the recording with has offered to lend
me an "interface"; from which I expect to learn /something/.

FWIW if you don't need the ultimate in quality I tend to suggest the
Scarlett 2i2 for making audio recordings. You can find info on it on my
website. I use it when I need to make recordings with a laptop. Note,
though, that it benefits from a 'quiet' power supply via USB. And will
drain the batteries of a laptop if used for very long. So for use with a Pi
you may find it needs to be powered via an added external hub.

That said, I've only used its 'line' inputs. But I've read good comments
about it from others.

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