Audio over wifi
 

Hello. I'm baffled and looking for help.

I've been trying to play audio over my home wifi :- the backend is a
raspbery pi sending audio out via USB into a DAC, the frontend is a laptop
running Debian 8, sending to a pulseaudio "SMC9514 hub digital stereo
(IEC958) on pi@raspberypi" sink (I find pulseaudio deeply obscure and
offputting, but I haven't found much else that offers the possibility of
doing this at all). This connects, to the extent of getting a noise out of
the speakers, but the sound is useless - broken up, stuttering, as much
silence than sound - it gives the impression that the data's just not being
sent fast enough.

Wifi-wise, the pi is the bottleneck, with 'iwconfig wlan0' giving "Bit
Rate=54 Mb/s" (the rest of the system could go faster). But handwavingly,
this is ~5megabytes/sec, CD-quality sound is ~10megabytes/min, so I'd have
expected that to be plenty.

(I've tried wav and a highly-compressed mp3, doesn't seem to make much
difference, I'm guessing it's decompressed before sending ? But it wouldn't
help anyway, having a DAC and cheap storage I don't want to use a lossy
format).

So what am I missing ? Is there some deep reason why this won't work, am I
doing something stupid, what's going on ?

TIA.

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

Hello. I'm baffled and looking for help.

I've been trying to play audio over my home wifi :- the backend is a
raspbery pi sending audio out via USB into a DAC, the frontend is a
laptop running Debian 8, sending to a pulseaudio "SMC9514 hub digital
stereo (IEC958) on pi@raspberypi" sink (I find pulseaudio deeply obscure
and offputting, but I haven't found much else that offers the
possibility of doing this at all). This connects, to the extent of
getting a noise out of the speakers, but the sound is useless - broken
up, stuttering, as much silence than sound - it gives the impression
that the data's just not being sent fast enough.

I can't comment in detail on the wifi beyond suspecting the obvious, that
it might be slow.

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.

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
 

Bob Latham 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 :- the backend is a
raspbery pi sending audio out via USB into a DAC, the frontend is a
laptop running Debian 8, sending to a pulseaudio "SMC9514 hub digital
stereo (IEC958) on pi@raspberypi" sink (I find pulseaudio deeply obscure
and offputting, but I haven't found much else that offers the
possibility of doing this at all). This connects, to the extent of
getting a noise out of the speakers, but the sound is useless - broken
up, stuttering, as much silence than sound - it gives the impression
that the data's just not being sent fast enough.

Wifi-wise, the pi is the bottleneck, with 'iwconfig wlan0' giving "Bit
Rate=54 Mb/s" (the rest of the system could go faster). But
handwavingly, this is ~5megabytes/sec, CD-quality sound is
~10megabytes/min, so I'd have expected that to be plenty.

(I've tried wav and a highly-compressed mp3, doesn't seem to make much
difference, I'm guessing it's decompressed before sending ? But it
wouldn't help anyway, having a DAC and cheap storage I don't want to use
a lossy format).

So what am I missing ? Is there some deep reason why this won't work, am
I doing something stupid, what's going on ?

As regards the rip format for music, unless you have extremely good
reasons for not doing so (I'm confident you haven't), use flac. Rip to

Thanks ... and, yes. New stuff comes in as flac. But ...

flac and get your tags sorted from the start rather have to come back
later and sort hundreds of albums.

.... I have a lot of 'historical' mp3s with no proper tagging, from the days
when storage was more of an issue. That's one reason why I'd prefer the
laptop hard disk to be my main storage, rather than put a hard disk behind
the raspbery pi - the laptop software/screen gives a nicer interface than
remotedestopping into the pi (I also have CDs to re-rip, which would be
easier that way). I could do the latter, if all else fails, but I want to
explore the alternative first, it'd just be a bit more convenient if I can
get it to work.

I'm not familiar with the kit you are using but FWIW here is my opinion.

My best guess is that you are trying to push music from a laptop to a
music renderer via wi-fi.

Yes.

I know many people push music via USB from a laptop directly into a dac

Yes. I've been doing that for a while, it works fine through a USB cable.
It's just that a cable stretched across the floor is not a good idea, sooner
or later I _will_ trip over it. I lost a nice pair of headphones that way
once; so wifi would be a better idea.

but I've never seen or heard of it being done with wi-fi in the link too.

I'm suprised; it seemed like the obvious next step, to me. Maybe I'm just
weird (shrug).

Personally, I've never liked the idea of 'push' music systems, it seems to
me that making sure the buffer in the renderer is neither overflowing or
empty is a bit tricky and far worse if you use wi-fi.

I advise using a pull system. The renderer pulls music from the server as
it requires it to keep the buffer just right. There are plenty of these
systems around.

Ah. That's a thing I hadn't taken seriously - I was guessing that given the
throughput numbers above, buffering wouldn't be an issue. Being proud of my
ability to be wrong, I will check out the idea of 'pull'.

To be clear, by a 'pull' system you mean that the music player software
lives on the machine that's wired into the amp (the pi, in my case) and it
sucks the music files down from a remote hard disk somewhere else on the
local network (the laptop, in my case) ?

Using flac I can stream hi-rez 192Khz/24bit music over wireless N all day
without an error but this does depend on how clear your local area is,
have you looked to see how many other wi-fi systems in your area are on
the same channel.

Ah, again. No, I hadn't, but will. I'm new to wifi in general, I've always
only done desktops/ethernet until I started playing with this stuff.

With pull systems, some pull from an SMB share on a PC or NAS eg. Sonos
and Bluesound and other systems pull from a UPnP server. Originally I
preferred the simplicity of the SMB connection but later I've seen the
advantage of UPnP, in particular there is only one central index no matter
how many clients/renderers. MinimServer is easy to setup - not a problem.

For your raspberry pi code Google OpenHome UPnP.

Thank you. This gives me some Things To Try Next.



I know others will not agree but that's life, not everyone will vote
"Leave" today either. :-)

Me, for example :-)




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

On Thu, 23 Jun 2016 08:28:04 -0500, Richard Robinson
wrote:

Bob Latham 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 :- the backend is a
raspbery pi sending audio out via USB into a DAC, the frontend is a
laptop running Debian 8, sending to a pulseaudio "SMC9514 hub digital
stereo (IEC958) on pi@raspberypi" sink (I find pulseaudio deeply obscure
and offputting, but I haven't found much else that offers the
possibility of doing this at all).

Not used a RPi, so can't help much with that at all. BTW, Jim is no
fan of pulse audio - neither am I, so I'm not grumbling - but
pulse audio or not, I suspect the WiFi is the problem, see below.

This connects, to the extent of
getting a noise out of the speakers, but the sound is useless - broken
up, stuttering, as much silence than sound - it gives the impression
that the data's just not being sent fast enough.

What transfer rate do you get if you just copy a file via WiFi from
the laptop to the RPi?

Wifi-wise, the pi is the bottleneck, with 'iwconfig wlan0' giving "Bit
Rate=54 Mb/s" (the rest of the system could go faster).

That sounds like it's telling you the theoretical maximum rate for
802.11g rather than the actual rate being achieved:
802.11b 2.4GHz 11 Mb/s
802.11g 2.4GHz 54 Mb/s
802.11n 2.4GHz 320 Mb/s

But
handwavingly, this is ~5megabytes/sec, CD-quality sound is
~10megabytes/min, so I'd have expected that to be plenty.

5MB/s is approximately equal to 54Mb/s (bytes vs bits), so, even if
you are being told the actual rate being achieved, you could easily be
maxing it out.

So what am I missing ? Is there some deep reason why this won't work, am
I doing something stupid, what's going on ?

I don't think your WiFi can be handling the throughput. You might
wish to investigate the coverage in as scientific a manner as
possible. It is generally accepted that to achieve a stable WiFi
connection, you need a signal-to-noise ratio of around -70dBm or
better. You can get smartphone/tablet apps that measure WiFi signals.
I have used an Android mobile phone app called WiFi Analyser, which I
rate as being pretty good ...
https://play.google.com/store/apps/d....wifi.analyzer
.... while for i* there's this, although I have no experience of it ...
https://itunes.apple.com/gb/app/netw...562315041?mt=8
Use one of these or something similar to check out the WiFi coverage.
--
================================================== ======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

Audio over wifi
 

On Thu, 23 Jun 2016 21:24:57 +0100, Java Jive
wrote:

On Thu, 23 Jun 2016 08:28:04 -0500, Richard Robinson
wrote:

Bob Latham 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 :- the backend is a
raspbery pi sending audio out via USB into a DAC, the frontend is a
laptop running Debian 8, sending to a pulseaudio "SMC9514 hub digital
stereo (IEC958) on pi@raspberypi" sink (I find pulseaudio deeply obscure
and offputting, but I haven't found much else that offers the
possibility of doing this at all).

Not used a RPi, so can't help much with that at all. BTW, Jim is no
fan of pulse audio - neither am I, so I'm not grumbling - but
pulse audio or not, I suspect the WiFi is the problem, see below.

This connects, to the extent of
getting a noise out of the speakers, but the sound is useless - broken
up, stuttering, as much silence than sound - it gives the impression
that the data's just not being sent fast enough.

What transfer rate do you get if you just copy a file via WiFi from
the laptop to the RPi?

Wifi-wise, the pi is the bottleneck, with 'iwconfig wlan0' giving "Bit
Rate=54 Mb/s" (the rest of the system could go faster).

That sounds like it's telling you the theoretical maximum rate for
802.11g rather than the actual rate being achieved:
802.11b 2.4GHz 11 Mb/s
802.11g 2.4GHz 54 Mb/s
802.11n 2.4GHz 320 Mb/s

But
handwavingly, this is ~5megabytes/sec, CD-quality sound is
~10megabytes/min, so I'd have expected that to be plenty.

5MB/s is approximately equal to 54Mb/s (bytes vs bits), so, even if
you are being told the actual rate being achieved, you could easily be
maxing it out.

So what am I missing ? Is there some deep reason why this won't work, am
I doing something stupid, what's going on ?

I don't think your WiFi can be handling the throughput. You might
wish to investigate the coverage in as scientific a manner as
possible. It is generally accepted that to achieve a stable WiFi
connection, you need a signal-to-noise ratio of around -70dBm or
better. You can get smartphone/tablet apps that measure WiFi signals.
I have used an Android mobile phone app called WiFi Analyser, which I
rate as being pretty good ...
https://play.google.com/store/apps/d....wifi.analyzer
... while for i* there's this, although I have no experience of it ...
https://itunes.apple.com/gb/app/netw...562315041?mt=8
Use one of these or something similar to check out the WiFi coverage.

Anyone who lives in a city is lucky if their wifi works at all.
Typically dozens of stations are crammed onto each channel, and the
signal is not the most robust. By London standards, my house is in a
pretty good location, but I still contend with this

http://www.soundthoughts.co.uk/look/wifi.png

d

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Audio over wifi
 

[interim followup, I haven't had a lot of time for this].

Java Jive said:
On Thu, 23 Jun 2016 08:28:04 -0500, Richard Robinson

Wifi-wise, the pi is the bottleneck, with 'iwconfig wlan0' giving "Bit
Rate=54 Mb/s" (the rest of the system could go faster).

That sounds like it's telling you the theoretical maximum rate for
802.11g rather than the actual rate being achieved:
802.11b 2.4GHz 11 Mb/s
802.11g 2.4GHz 54 Mb/s
802.11n 2.4GHz 320 Mb/s

I suspected that. Then I shuffled stuff around the network for a while to
make sure it had enough reality to chew on then looked again, and it told
me, variously, 180Mb/s and 216Mb/s. So I think it's real numbers - which I
also don't understand, the card only claiming to be capable of up to
150Mb/s. I have v. little experience of network diagnostics.


But handwavingly, this is ~5megabytes/sec, CD-quality sound is
~10megabytes/min, so I'd have expected that to be plenty.

5MB/s is approximately equal to 54Mb/s (bytes vs bits), so, even if you
are being told the actual rate being achieved, you could easily be maxing
it out.

That's what I don't see, 5 megabytes / second is much faster than 10
megabytes / minute. Bob Latham's comment on buffering may be the answer,
I'll investigate that when my tuits arrive. But not being in an energetic
mood today, I think I'll also look at Volumio.

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

On 06/23/2016 12:40 PM, Bob Latham wrote:

For your raspberry pi code Google OpenHome UPnP.

I'm getting good results with MPD in the Pi with the music on another
machice as a file server. OK, sometimes FLAC tracks are a little slow
to start but generally it is good.

If you are handy with scripting and the filenames / directory names are
meaningful could you write a tagging script for those MP3s?

Pete

Audio over wifi
 

Peter Chant said:
On 06/23/2016 12:40 PM, Bob Latham wrote:

For your raspberry pi code Google OpenHome UPnP.

I'm getting good results with MPD in the Pi with the music on another
machice as a file server. OK, sometimes FLAC tracks are a little slow
to start but generally it is good.

Yes, that's looking like my next step. I looked at volumio and a couple of
the other dedicated audio distros, but I couldn't get them to even boot and
have reached the point where MPD's looking like a more worthwhile option
than throwing any more time at them.

How does accessing the remote disk work, do you need NFS/Samba, somthing
like that ? I've never needed anything like that before (it's not a problem,
I can do Geek when I have to).

If you are handy with scripting and the filenames / directory names are
meaningful could you write a tagging script for those MP3s?

Kid3 can do that with a button-push. Which is nice, in cases where the
filenames are meaningful. Cue hollow laughter - well, some of them are, but
plenty aren't.

$ find /home/music | egrep '/01.(mp3|flac)' | wc -l
259

Directory names are meaningful, as they more-or-less have to be, I could
script that, but it's not worth it - if I've to be doing the individual
tracks by hand it's hardly any extra nuisance to slap the 'Album' name in at
the same time. I do find Kid3 pretty convenient. And in the meantime, I have
players that'll browse the filesystem as well as the tags.

But I have written a perl script to check for and apply ReplayGain, which
seems to work, and improves things.


Which all reminds me - is there any way of storing tag data outside the
music file ? It's irritating, and slow, having to back up music files in
their entirety when I've only made changes to the tag data.

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

On 06/27/2016 01:12 PM, Richard Robinson wrote:
Peter Chant said:
On 06/23/2016 12:40 PM, Bob Latham wrote:

For your raspberry pi code Google OpenHome UPnP.

I'm getting good results with MPD in the Pi with the music on another
machice as a file server. OK, sometimes FLAC tracks are a little slow
to start but generally it is good.

Yes, that's looking like my next step. I looked at volumio and a couple of
the other dedicated audio distros, but I couldn't get them to even boot and
have reached the point where MPD's looking like a more worthwhile option
than throwing any more time at them.


I believe that and others use mpd as a backend.

How does accessing the remote disk work, do you need NFS/Samba, somthing
like that ? I've never needed anything like that before (it's not a problem,
I can do Geek when I have to).

mpd can apparently connect directly to a smb or nfs server. In my
config I mount the nfs director using /etc/fstab. Partly as I did not
realise mpd could connect to the server directly.


Which all reminds me - is there any way of storing tag data outside the
music file ? It's irritating, and slow, having to back up music files in
their entirety when I've only made changes to the tag data.


Don't know. Playlist per album?

Audio over wifi
 

Peter Chant said:
On 06/27/2016 01:12 PM, Richard Robinson wrote:
Peter Chant said:
On 06/23/2016 12:40 PM, Bob Latham wrote:

For your raspberry pi code Google OpenHome UPnP.

I'm getting good results with MPD in the Pi with the music on another
machice as a file server. OK, sometimes FLAC tracks are a little slow
to start but generally it is good.

Yes, that's looking like my next step. ...

! I do believe I have it working. And, yes, pull does the job where push didn't.

How does accessing the remote disk work, do you need NFS/Samba, somthing
like that ? I've never needed anything like that before (it's not a problem,
I can do Geek when I have to).

mpd can apparently connect directly to a smb or nfs server. In my
config I mount the nfs director using /etc/fstab. Partly as I did not
realise mpd could connect to the server directly.

I dunno. I did set up nfs, it was so little hassle I don't even know if it
was necessary or not. Fiddling about with alsa/pulseaudio configuration was
nastier, as &^%$! always.

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

Audio over wifi
 

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

Audio over wifi
 

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

Audio over wifi
 

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

Audio over wifi
 

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

Audio over wifi
 

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

Audio over wifi
 

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

Audio over wifi
 

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

Audio over wifi
 

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

Audio over wifi
 

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

Audio over wifi
 

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

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