Posts Tagged RPi
Ripping Vinyl Records on a Raspberry Pi
Posted by Ed in Electronics Workbench, Software on 2019-09-05
Having already set up a Raspberry Pi streaming radio player for the living room, it seemed reasonable to also use it for recording audio from the long-disused turntable. A pair of RCA cables from the amplifier’s TAPE 2 REC outputs to the Behringer UCA202 USB audio interface got the audio where it needed to be:
Fiddle with the amp to select the phonograph, poke the TAPE 2 button to send audio to/from the UCA202, fire up an SSH session, kill the streaming audio program, and figure out what audio hardware is out there:
$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: CODEC [USB Audio CODEC], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0Not much else to choose from on a Raspberry Pi, so see what the UCA202 can do:
$ arecord --dump-hw-params
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "default":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S8 S16_LE
SUBFORMAT: STD
SAMPLE_BITS: [8 16]
FRAME_BITS: [8 32]
CHANNELS: [1 2]
RATE: [8000 48000]
PERIOD_TIME: [1000 65536000]
PERIOD_SIZE: [16 524288]
PERIOD_BYTES: [64 524288]
PERIODS: [2 1024]
BUFFER_TIME: (666 131072000]
BUFFER_SIZE: [32 1048576]
BUFFER_BYTES: [64 1048576]
TICK_TIME: ALL
--------------------
arecord: set_params:1233: Sample format non available
Available formats:
- S8
- S16_LEGiven those limited choices, 16 bit little-endian at 48 kHz seems like a no-brainer.
Find out all the ALSA device names:
$ arecord -L
null
Discard all samples (playback) or generate zero samples (capture)
sysdefault:CARD=CODEC
USB Audio CODEC, USB Audio
Default Audio Device
front:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Front speakers
surround21:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
4.0 Surround output to Front and Rear speakers
surround41:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
IEC958 (S/PDIF) Digital Audio Output
dmix:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Direct sample mixing device
dsnoop:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Direct sample snooping device
hw:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Direct hardware device without any conversions
plughw:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Hardware device with all software conversionsThey all point to the same hardware, so AFAICT the default device will work fine.
Try recording something directly to the RPi’s /tmp directory, using the --format=dat shortcut for “stereo 16 bit 48 kHz” and --mmap to (maybe) avoid useless I/O:
$ arecord --format=dat --mmap --vumeter=stereo --duration=$(( 30 * 60 )) /tmp/Side\ 1.wav
Recording WAVE '/tmp/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
+02%|01%+ overrun!!! (at least 1.840 ms long)
+02%|02%+ overrun!!! (at least 247.720 ms long)
+# 07%|06%##+ overrun!!! (at least 449.849 ms long)
+ 03%|02%+ overrun!!! (at least 116.850 ms long)Huh. Looks like “writing to disk” sometimes takes far too long, which seems to be the default for MicroSD cards.
The same thing happened over NFS to the file server in the basement:
$ arecord --format=dat --mmap --vumeter=stereo --duration=$(( 30 * 60 )) /mnt/part/Transfers/Side\ 1.wav
Recording WAVE '/mnt/part/Transfers/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
+ 09%|07% + overrun!!! (at least 660.372 ms long)
+# 08%|06%# + overrun!!! (at least 687.906 ms long)
So maybe it’s an I/O thing on the RPi’s multiplexed / overloaded USB + Ethernet hardware?
Trying a USB memory jammed into the RPi, under the assumption it might be better at recording than the MicroSD Card:
$ arecord --format=dat --mmap --vumeter=stereo --duration=$(( 30 * 60 )) /mnt/part/Side\ 1.wav
Recording WAVE '/mnt/part/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
+01%|01%+ overrun!!! (at least 236.983 ms long)Well, if it’s overrunning the default buffer, obviously it needs Moah Buffah:
$ arecord --format=dat --mmap --vumeter=stereo --buffer-time=1000000 --duration=$(( 30 * 60 )) /mnt/part/Side\ 1.wav
Recording WAVE '/mnt/part/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
+## 10%|06%# + overrun!!! (at least 359.288 ms long)When brute force doesn’t work, you’re just not using enough of it:
$ arecord --format=dat --mmap --vumeter=stereo --buffer-time=2000000 --duration=$(( 30 * 60 )) /mnt/part/Side\ 1.wav
Recording WAVE '/mnt/part/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
+00%|00%+ Sampling four bytes at 48 kHz fills 192 kB/s, so a 2 s buffer blots up 384 kB, which seems survivable even on a Raspberry Pi.
The audio arrives at 11.5 MB/min, so an LP side with 20 min of audio will require about 250 MB of disk space. The USB memory was an ancient 2 GB card, so all four sides filled it halfway:
$ ll /mnt/part
total 1.1G
drwxr-xr-x 2 ed root 4.0K Dec 31 1969 ./
drwxr-xr-x 17 root root 4.0K Jun 7 19:15 ../
-rwxr-xr-x 1 ed root 281M Sep 1 14:38 'Side 1.wav'*
-rwxr-xr-x 1 ed root 242M Sep 1 15:01 'Side 2.wav'*
-rwxr-xr-x 1 ed root 265M Sep 1 15:27 'Side 3.wav'*
-rwxr-xr-x 1 ed root 330M Sep 1 15:58 'Side 4.wav'*Side 4 is a bit longer than the rest, because I was folding laundry and the recording stopped at the 30 minute timeout after 10 minutes of silence.
Now, to load ’em into Audacity, chop ’em into tracks, and save the lot as MP3 files …
Raspberry Pi vs. MicroSD: Another One Bites the Dust
Posted by Ed in Electronics Workbench, Machine Shop on 2019-08-20
The Raspberry Pi running the MPCNC recently seized up with baffling symptoms, which generally indicates the poor little MicroSD card serving as a “hard disk” has failed:
I managed to open a terminal emulator, whereupon all of the non-built-in shell commands couldn’t be found.
Proceed as before: binary-copy the entire MicroSD card to another one, pop it in the RPi, and it’s all good again.
For the record, the new card is an unused Samsung Evo Plus. I do not understand the difference between the “Evo Plus” and “Evo+” branding, other than to suspect one of being a very good fake.
In round numbers, MicroSD cards seem to last a year under what seems like not-too-demanding service; I’m not running the MPCNC all day, every day.
Logitech “QuickCam Pro 5000” Ball Camera Disassembly
Posted by Ed in Machine Shop, Photography & Images on 2019-08-16
Another alignment camera contestant from the Big Box o’ Junk Cameras:
It’s a Logitech QuickCam Pro 5000 with a native 640×480 resolution. For no obvious reason, it seems to work better on a Raspberry Pi than the Logitech QuickCam for Notebooks Deluxe I ripped apart a few weeks ago, where “better” is defined as “shows a stable image”. I have no explanation for anything.
Remove the weird bendy foot-like object by pulling straight out, then remove the single screw from the deep hole visible just behind the dent in the top picture:
The stylin’ curved plate on the top holds the microphone and a button, neither of which will be of use in its future life. Unplug and discard, leaving the USB cable as the only remaining connection:
Inexplicably, the cable shield is soldered to the PCB, so the connector doesn’t do much good. Hack the molded ball off of the cable with a diagonal cutter & razor knife, taking more care than I did to not gouge the cable insulation.
A glue dot locks the focusing threads:
Gentle suasion with a needle nose pliers pops the dot, leaving the lens free to focus on objects much closer than infinity:
Now, to conjure a simpleminded mount …
Xiaomi-Dafang Hacks: FTP Server for Camera Files
Posted by Ed in Home Ec, Photography & Images, Software on 2019-08-09
Since the PiHole runs all the time, it now hosts an FTP server to stash snapshots from the cameras onto a 64 GB USB stick. I installed ProFTPD, which Just Worked with a few configuration tweaks:
UseIPv6 off
ServerName "PiHole"
DefaultRoot /mnt/cameras
RequireValidShell offThe cameras use the BusyBox ftpput command to stash their images (with the hostname prepended), which requires a few changes to motion.conf in the cameras:
ftp_snapshot=true
ftp_host="192.168.1.2"
ftp_port=21
ftp_username=$(/bin/hostname)
ftp_password="make up your own"
ftp_stills_dir=$(/bin/hostname)The last line uses a separate directory for each camera, although they quickly ran into the FAT32 limit of 64 K files per directory; reformatting the USB stick with an ext3 filesystem solved that problem.
Fortunately, nothing much ever happens around here …
Algorithmic Art
Posted by Ed in Electronics Workbench, Machine Shop on 2019-07-10
This evening I’ll be showing off my Algorithmic Art at the HV Open Mad Science Fair.
There’ll be glowing glassware:
Ancient electronics with modern hardware:
Blinking LEDs atop Brutalist analog electronics:
A classic HP 7475A plotter hammering math onto paper from a Raspberry Pi running Chiplotle:
Some take-home art:
And, as always, a good time will be had by all!
3D Printing: Peculiar Octopi Problem
Posted by Ed in Electronics Workbench, Machine Shop, Oddities, Software on 2019-03-07
From a discussion on the Makergear 3D printer forums …
A Makergear M2 user had a strange problem:
Octopi claims the serial connection went down.
LED2 was blinking red, rapidly, and LED3 was shining with a steadfast red light.
LED2 shows the extruder heater PID loop is running and LED3 shows the extruder fan is on:
https://reprap.org/wiki/Rambo_v1.1
You just never noticed the blinkiness before … [grin]
Because the extruder heater is still running, the firmware hasn’t detected a (possibly bogus) thermal runaway or any other fatal problem. It’s just waiting for the next line of G-Code, but Octopi isn’t sending it.
Casually searching the GitHub issues, there’s a report of intermittent serial problems from last year:
https://github.com/foosel/OctoPrint/issues/2647
Which points to the FAQ:
https://community.octoprint.org/t/octop … eption/228
Look at the Octopi Terminal log to see if the conversation just before the failure matches those descriptions.
Assuming you haven’t updated the printer firmware or anything on the Octopi, then something physical has gone wrong.
First and least obviously, the Pi’s MicroSD card has probably started to fail: they’re not particularly durable when used as a mass storage device and “the last couple of years” is more than you should expect. Download a fresh Octopi image, put it on a shiny-new, good-quality card (*), and see if the situation improves.
Then I’d suspect the Pi’s power supply, even though you’re using the “official rpi power supply”. All of those things contain the cheapest possible electrolytic capacitors, running right on the edge of madness, and produce bizarre errors when they begin to go bad. Get a good-quality wall wart (**), ideally with a UL rating, and see if the situation improves.
While you’re buying stuff, get a good-quality USB cable (***) to replace the one that (assuming you’re like me) you’ve been saving for the last decade Just In Case™. Use the shortest cable possible, because longer does not equal better.
After that, the problems get truly weird. Apply some tweakage and report back.
(*) This is harder to do than you might think. You may safely assume all cards available on eBay and all “Sold by X, Fulfilled by Amazon” cards will be counterfeit crap. I’ve been using Samsung EVO / EVO+ cards (direct from Samsung) with reasonable success:
https://softsolder.com/2018/10/16/raspb … sk-memory/
https://softsolder.com/2017/11/22/samsu … ification/
https://www.samsung.com/us/computing/me … 22y+zq29p/
The card in question eventually failed, so having a backup card ready to go was a Good Idea™.
(**) Top-dollar may not bring top quality, but Canakit has a good rep and costs ten bucks through Prime.
(***) Amazon Basics cables seems well-regarded and work well for what I’ve needed.
Icecast and Ezstream Configuration
Plugging a 64 GB USB stick with directories full of MP3 / OGG files into an always-on Raspberry Pi running Pi-Hole, one can use Icecast to stream them for clients on the LAN, so as to avoid over-the-Intertubes streaming issues.
The only changes in the /etc/icecast2/icecast.xml file cover passwords, the number of source streams, and the hostname. It’s that simple, really.
Given a directory of files, generate a file-per-line playlist:
find /mnt/music/goodmusic/ -name \*mp3 | sort > /mnt/music/goodmusic/playlist.m3u
Then set up a corresponding Ezstream XML file, perhaps imaginatively named goodmusic.xml:
<ezstream>
<url>http://localhost:8000/goodmusic</url>
<sourcepassword>make-up-your-own</sourcepassword>
<format>MP3</format>
<filename>/mnt/music/goodmusic/playlist.m3u</filename>
<shuffle>1</shuffle>
<stream_once>0</stream_once>
<svrinfoname>Good Music</svrinfoname>
<svrinfourl>pihole.local</svrinfourl>
<svrinfogenre>Good Music Streaming 24x7</svrinfogenre>
<svrinfodescription>Techno Dub</svrinfodescription>
<svrinfobitrate>128</svrinfobitrate>
<svrinfochannels>2</svrinfochannels>
<svrinfosamplerate>44100</svrinfosamplerate>
<svrinfopublic>1</svrinfopublic>
</ezstream>
Fire off the source stream in /etc/rc.local:
ezstream -c /home/pi/Icecast/goodmusic.xml &
The ampersand tells Bash to fire-and-forget the process, so it runs all the time. One could, I suppose, put it in crontab to start after each boot or puzzle out the corresponding systemd incantation, but …
Add the station to your streaming media player:
'KEY_KP5' : ['Good Music',False,['mplayer','-playlist','http://192.168.1.2:8000/goodmusic.m3u']],
And then It Just Works™.
Blowback