Raspberry Pi 3

[levi]

Apparently when Eben released the Pi 3 he thought it was finally powerful enough, so there was supposedly no plan for a revision of that board. I'm not sure how true that still is, unless you're determine to run it with no heatsink inside a plastic box. I'm not aware of a newer ARM spec that's significantly more efficient than the chips in the Pi3 within a specific low power envelope.

 

[ible]

https://liliputing.com/2018/03/rasp...d-model-b-with-faster-cpu-and-networking.html

just had to wait for pi day. btw, happy pi day!

 

[levi]

For anyone who doesn't know, it's called Pi Day because it's the third month (March) day 14, and because Americans would write that as 3.14, that's Pi to 3 s.f.

And as it happens, it might just have taken farnell down. I was halfway through checking out what the price would be this side of the pond, and now I can't get back in the the site.

 

[Ian J]

I'm tempted by the 3B but I really wanted a bigger leap in CPU speed.

 

[ible]

3B+ i think you mean. i might be fine with these specs. or i might wait for the 4C.

 

[klapse]

I'm tempted by the 3B but I really wanted a bigger leap in CPU speed.

Well to do what. The pi3 is already a supercomputer by 80s standards.

It can do 60fps 1080p video in a pretty heavy format (h264).

Oh you mean you want to 'browse the web' where bluehaired hipster hirees can't put text and graphics on a screen without forcing a gigahertz cpu to its knees?

The problem isn't too-slow computers.

 

[levi]

To a certain extent that still depends what you want to do with it. There are increasingly good reasons to run your OS under a hypervisor or in virtualisation (not sure if the chip on the Pi 3 has a hypervisor ring) which eats a chunk of your cpu cycles (although probably not that much in the scale of things) and how about things like playing 4K video, and transcoding videos - I have a slow computer that can't handle 1080p videos with a web browser and mail reader open, so I generally transcode them down to the screen resolution, so I usually download them to my faster build server and transcode them there before scping them back for local play, but that transcoding on my build server is still running at less than 0.5x.

Also there's file compression. FLIF is pretty incredible for images, but for general data some of the more recent algorithms can chew cpu cycles like there's no tomorrow. Back in the 1980s we never compressed anything apart arguably from sampled music using modfiles. Technically I think GIF first came out in 1987, although I don't think I came across them until the mid-early 1990s.

 

[Ian J]

It can do 60fps 1080p video in a pretty heavy format (h264).

Some blu-ray rips made the temperature warning come on screen but the main reason for a faster CPU is to make more games playable in MAME

 

[Ian J]

Bit disappointed with the RPi community as I've a project but no-one seems to be able to help, I've joined various forums but apparently my project is beyond the reach of any of their members.

I want to use the Pi as a music player in the car (connected to the existing head unit via AUX in) but I don't want a screen on the RPi.

All I want is the RPi to play from an SD card (continue where it left off) when power is turned on and shut off when power is removed.

If I can add a couple of buttons for next and previous track that would be a bonus.

I know I need one of these to safely shut down the Pi but past that I can get no help on which music player to use or how to get it to continue when power is re-applied

https://www.mausberrycircuits.com/c...pply-switches/products/3a-car-supply-switch-1

 

[ible]

i have a bitbox running music for my son's play time, and it iterates through songs on an sd card:
https://github.com/lowagner/bitbox-noisebox
not super hi-fi or anything, though, just 8 bit wavs "streamed" from the sd card.

thankfully the bitbox has a button for control (though i've only programmed it to skip songs or fast-forward), so i can run it "headless" (but not soundless ).

as for the rpi, you can probably do something like that using bash and mplayer, and put it in a startup script. (bash to keep track of the last song you've played in a file somewhere, mplayer to play the songs.)

 

[levi]

I hacked deadbeef back in the day to always update its config when a new song started, so it would always pick up at least at the start of the last file started. That's not exactly headless though, and only runs when GTK is available as far as I know.

mplayer can certainly run headless though, and can be prompted with playlist files that are simply one line per file format. There's a warning in the docs that the playlist parser isn't completely secure against explicitly invalidly written files, but if you're writing your playlists yourself or via scripts you've written then that should be fine. Although the easiest way to do this is probably write your own parser - you can pull the top line off a file using 'head -1' and the rest can be dumped out again into a file using 'tail -n +2', although if you've any spaces in your filenames that'll be a bit of a faff, at least if you're trying to do it all in one command line using xargs like I am. If you're using temp files you could have a bit more leeway, but I find managing those a bit of a headache myself.

 

[PowerGod]

Have you tried Rockbox ? You can make the OS to launch it at startup, and its controls are optimized for no use of display, it also have an auto-resume-play-at-startup option

 

[kaprikawn]

Bit disappointed with the RPi community as I've a project but no-one seems to be able to help, I've joined various forums but apparently my project is beyond the reach of any of their members.

I want to use the Pi as a music player in the car (connected to the existing head unit via AUX in) but I don't want a screen on the RPi.

All I want is the RPi to play from an SD card (continue where it left off) when power is turned on and shut off when power is removed.

If I can add a couple of buttons for next and previous track that would be a bonus.

I know I need one of these to safely shut down the Pi but past that I can get no help on which music player to use or how to get it to continue when power is re-applied

https://www.mausberrycircuits.com/c...pply-switches/products/3a-car-supply-switch-1

View attachment 31618

If I were doing this, I'd be looking at systemd services to start the music player on bootup (assuming the Raspberry Pi has systemd, I don't know how far behind on Debian they are). Getting it to auto play would be the tricky part, but I doubt it would be an insurmountable problem. And I'd look to either ncmpcpp or cmus as the music player. One of those probably has some sort of startup script facility.

 

[klapse]

If I were doing this, I'd be looking at systemd services to start the music player on bootup (assuming the Raspberry Pi has systemd, I don't know how far behind on Debian they are). Getting it to auto play would be the tricky part, but I doubt it would be an insurmountable problem. And I'd look to either ncmpcpp or cmus as the music player. One of those probably has some sort of startup script facility.

"Because we need systemd to start something on boot"

[the rest is self-censored]

 

[levi]

I'm not so sure. Assuming it's auto logging in what's wrong with putting it in your .bashrc or what have you?

I say this having tried to add a service to systemd to ring the system bell just before it asks for my partition unlock password on my headless box. The first experience, in getting systemd to spit out an ordered graphical list of boot units in a sort of gantt chart thing as an .svg file, which seemed to make it very clear how I could hook into it, gave me a very promising feeling of progress. And yet, everything I tried (including Wants= this, After= that and Before= the other) locked the system before login and sshd start, so I ended up giving up and learning that I could watch the keyboard lights to save having to sit in front of the slighty inaccessible disc drive light from power up - the caps lock light comes on throughout grub's menu and only turns off once the kernel is loaded and starts booting. I can then watch the drive light and as soon as it goes out, it's time to enter my password.

 

[pimaster]

Bit disappointed with the RPi community as I've a project but no-one seems to be able to help, I've joined various forums but apparently my project is beyond the reach of any of their members.

I want to use the Pi as a music player in the car (connected to the existing head unit via AUX in) but I don't want a screen on the RPi.

All I want is the RPi to play from an SD card (continue where it left off) when power is turned on and shut off when power is removed.

If I can add a couple of buttons for next and previous track that would be a bonus.

I know I need one of these to safely shut down the Pi but past that I can get no help on which music player to use or how to get it to continue when power is re-applied

https://www.mausberrycircuits.com/c...pply-switches/products/3a-car-supply-switch-1

View attachment 31618

Linux is just a bunch of tools. You should be able to string them together to achieve what you want. There is nothing special about the Pi that you need to go to them for.
mpd (music player daemon) is the package you want to install. You also want to install mpc (music player client) and possibly ncmpc (ncurses music player client).
Configure mpd by editing /etc/mpd.conf
Because you are loading from SD card you want to make sure that is mounting each time the pi starts (different problem) and to a known location.

For the 'playing all music on the device' problem, you will need to execute
mpc --wait update -q; mpc crop -q; mpc listall -q | shuf | mpc add -q; mpc play -q
each time the pi boots.
You want to force a database update.
Crop the play list to the current song.
Add all songs to the playlist.
Play (incase it was at the end of the song and the playlist finished).

This does mean the playlist contains the current playing song twice. Should look at trying to fix that.
Also, the playlist is fixed whilst the pi remains powered. This may or may not be a problem.

You need to configure mpd to loop through the current play list.
You can get keyboard access to the player through ncmpc to go forward/back/vol up/down etc.

--edit-- Removing the dup
mpc --wait update -q; mpc crop -q; mpc listall | shuf | mpc add -q; mpc play -q; mpc current --wait; mpc del 1
We can wait for the current song to change (mpc current --wait) then remove the first item in the playlist (mpc del 1).
The current song could still be anywhere in the playlist but this would do me.

 

[kaprikawn]

"Because we need systemd to start something on boot"

[the rest is self-censored]

If you don't like systemd then fine, install your Deuvan (or Gentoo or Slackware or whatever). But there's someone who is trying to get something up and running on a modern system, it makes sense to advise them to use the currently accepted practice for managing services. And that's systemd right now.

 

[Ian J]

Linux is just a bunch of tools. You should be able to string them together to achieve what you want. There is nothing special about the Pi that you need to go to them for.
mpd (music player daemon) is the package you want to install. You also want to install mpc (music player client) and possibly ncmpc (ncurses music player client).
Configure mpd by editing /etc/mpd.conf
Because you are loading from SD card you want to make sure that is mounting each time the pi starts (different problem) and to a known location.

For the 'playing all music on the device' problem, you will need to execute
mpc --wait update -q; mpc crop -q; mpc listall -q | shuf | mpc add -q; mpc play -q
each time the pi boots.
You want to force a database update.
Crop the play list to the current song.
Add all songs to the playlist.
Play (incase it was at the end of the song and the playlist finished).

This does mean the playlist contains the current playing song twice. Should look at trying to fix that.
Also, the playlist is fixed whilst the pi remains powered. This may or may not be a problem.

You need to configure mpd to loop through the current play list.
You can get keyboard access to the player through ncmpc to go forward/back/vol up/down etc.

--edit-- Removing the dup
mpc --wait update -q; mpc crop -q; mpc listall | shuf | mpc add -q; mpc play -q; mpc current --wait; mpc del 1
We can wait for the current song to change (mpc current --wait) then remove the first item in the playlist (mpc del 1).
The current song could still be anywhere in the playlist but this would do me.

Many thanks for your help with this I really appreciate it, I'm a complete Linux noob so please bear with me.

I've installed mpd, mpc and ncmpc

I've edited the mpd.conf file and added in the location of my music files on the SD card (/home/pi/Music tracks are in separate folders in here) and a folder for play-lists

I've tried running the mpc command line but all I get back is a warning that a playlist of at least 1 song is required to crop, what am I doing wrong?

EDIT:

Got a bit nearer, now get the message: mpd error: connection refused

 

[pimaster]

The problem with the crop command is one I didn't consider. I was tinkering around with the whole setup before I came up with the line of commands that I didn't consider a 'fresh start'. Glad you seem to have got passed it though.

Connection refused might refer to many things.
mpd > audio device.
mpc > mpd.

Is mpd running? "/etc/init.d/mpd status"
Do you get anything interesting out of "ncmpc"?
There is a log file in /var/log/mpd/<something>. Does that give you any insight.

I'm a complete Linux noob so please bear with me.

I'll do my best but make sure you give google a quick check before coming back with each problem

 

[klapse]

If you don't like systemd then fine, install your Deuvan (or Gentoo or Slackware or whatever). But there's someone who is trying to get something up and running on a modern system, it makes sense to advise them to use the currently accepted practice for managing services. And that's systemd right now.

https://it.slashdot.org/story/17/07...-code-execution-for-two-years?sdsrc=popbyskid

You haven't been on the planet, and woke, for long enough to see when something hits a scene unnaturally fast - in any realm. That's an almost sure sign for a manifestation of evil.

And finally, the lamest vendor response award went to Systemd supremo Lennart Poettering for his controversial, and perhaps questionable, handling of the following bugs in everyone's favorite init replacement: 5998, 6225, 6214, 5144, and 6237... "Where you are dereferencing null pointers, or writing out of bounds, or not supporting fully qualified domain names, or giving root privileges to any user whose name begins with a number, there's no chance that the CVE number will referenced in either the change log or the commit message," reads the Pwnie nomination for Systemd, referring to the open-source project's allergy to assigning CVE numbers. "But CVEs aren't really our currency any more, and only the lamest of vendors gets a Pwnie!"