Where do you get that any multiple of 44.1 will not be clocked accurately with a pi? Just curious.
Roberto
Finally I succeeded to create a working image of Moode 4b12.
I started testing how it works and I have to say that this is a great piece of software... better than best it was...
Congratulation for your effort.
I started to mess about bluetooth stuff and everything works fine but the pairing.
The problem is the following, when a device start the pairing, the bluetooth stack (on rPi) accept the pairing, but the connection can't start from the device. You will experience a connection/disconnection loop.
I found that if I insert the MAC addr of the client into the trusted list via bluetoothctl, then a device can connect to rPi flawlessly.
# bluetoothctl
trust AA:BB:CCD:EE:FF
I'm trying to understand if an "auto trust" procedure can be implemented in order to make this working out of the box, but I didn't find a solution yet, I don't have much time to work on.
I started testing how it works and I have to say that this is a great piece of software... better than best it was...
Congratulation for your effort.
I started to mess about bluetooth stuff and everything works fine but the pairing.
The problem is the following, when a device start the pairing, the bluetooth stack (on rPi) accept the pairing, but the connection can't start from the device. You will experience a connection/disconnection loop.
I found that if I insert the MAC addr of the client into the trusted list via bluetoothctl, then a device can connect to rPi flawlessly.
# bluetoothctl
trust AA:BB:CC
D:EE:FFI'm trying to understand if an "auto trust" procedure can be implemented in order to make this working out of the box, but I didn't find a solution yet, I don't have much time to work on.
Re: Post #12173,
randytsuch, couldn't agree more. Frankly, I can't understand why the MPD guy would do such a thing...if you're intent is to get your software out there, this doesn't seem like the way to do it...some kind of limited license agreement with Tim seems like a much better approach...
It is unfortunate for non-linux gurus/audiophiles...
Speaking of non-linux gurus, I do not consider myself, nor am I, a linux guru. I', pretty good at find my way around a computer though...
Please see Post #11985, I've built multiple image files of Moode Audio 4.0 Beta 12 using what I wrote...maybe this will help you.
randytsuch, couldn't agree more. Frankly, I can't understand why the MPD guy would do such a thing...if you're intent is to get your software out there, this doesn't seem like the way to do it...some kind of limited license agreement with Tim seems like a much better approach...
It is unfortunate for non-linux gurus/audiophiles...
Speaking of non-linux gurus, I do not consider myself, nor am I, a linux guru. I', pretty good at find my way around a computer though...
Please see Post #11985, I've built multiple image files of Moode Audio 4.0 Beta 12 using what I wrote...maybe this will help you.
Thanks for those links. But I couldn't even read the sd card on my pc after writing the image.
I just downloaded puppy linux, an easy way to run linux on a PC. Write the image to a usb stick, boot from the stick and you have linux running.
On Pi i2s clocking, hifiduino also wrote about it in his blog
Raspberry Pi I2S | H i F i D U I N O
I thought it was pretty much common knowledge.
Last edited:
Thanks for the answer, so I understand why Tim doesn't distribute an image.
IMHO, Heeboo has the right approach. Make a script that adds moode to a working Pi. But I may be biased because that was the only way I could get moode working lol.
Randy
I rather suspect that blog entry is too technical for many but it is superb. A good moral can be found in the discussion toward the end. Other SBCs have some great design characteristics in their favor (like the writer, I was a Beaglebone Black fanboy; still am for some applications, like CNC and robotics), but as the blog entry says "there has been a much larger development effort in the RPi front." That was true 3 years ago when the entry was written and even more true today.
I don't understand why you "...couldn't even read the sd card on my pc after writing the image". By PC, do you mean a Microsoft Windows host? Did you unplug the card and plug it back in after writing the image? The recent versions of Windows I've used (only when I have too!) will autodetect and mount the first partition because it's formatted FAT32. That partition contains the text files that need editing.
As for running Linux on a PC, there are so many ways to skin that cat I wouldn't want to enumerate them all. Haven't felt the need to use Puppy Linux in years. Glad to hear it's still alive and kicking 15 years on.
...and, of course, glad to hear you persevered and now have a working moOde installation.
Regards,
Kent
This is in a windows 7, 32 bit OS PC. I can also run windows 10 64 on the same PC (I have licences for both and swap SSDs), but the w10 is more for audio use, so using w7 for generic use.
After I wrote the image to the card, the card didn't show up as a drive anymore on this PC. At least that's what I remember. I didn't really look into it, I figured it was because they were linux files, so I moved the card to my my mac to work on them.
But I see your point about fat32 and that windows should still see the files, could have been pilot error on my part.
And yes, puppy is alive and well as far as I can tell. I'm sure there are ways now to read a linux disk from a windows pc, at some point I may have to try one.
I also have a BBB sitting on a shelf, may try installing something (rune?) on that, and see how it sounds compared to pi/moode.
i used the install procedure from the website:
Enter these commands via SSH on a Raspberry Pi running Raspbian.
1. Download the Image Builder
cd /home/pi
sudo wget -q http://moodeaudio.org/downloads/mos/mosbuild.sh -O /home/pi/mosbuild.sh
sudo chmod +x /home/pi/mosbuild.sh
2. Start the Image Builder
sudo ./mosbuild.sh
after this booted from the new sd card.
rasbian is starting.
but no moode webinterface (and no i did not use a proxy)
I think i will leave moode and go to an other OS for audio.
I understand that this is free software but this new install procedure is not user friendly at all...
2x SD card and usb to SD card and search through 12xxx posts on this forum.
I need a descent manual.
i just want to listen to music on my es9018 buffalo dac.
Enter these commands via SSH on a Raspberry Pi running Raspbian.
1. Download the Image Builder
cd /home/pi
sudo wget -q http://moodeaudio.org/downloads/mos/mosbuild.sh -O /home/pi/mosbuild.sh
sudo chmod +x /home/pi/mosbuild.sh
2. Start the Image Builder
sudo ./mosbuild.sh
after this booted from the new sd card.
rasbian is starting.
but no moode webinterface (and no i did not use a proxy)
I think i will leave moode and go to an other OS for audio.
I understand that this is free software but this new install procedure is not user friendly at all...
2x SD card and usb to SD card and search through 12xxx posts on this forum.
I need a descent manual.
i just want to listen to music on my es9018 buffalo dac.
Maybe this can help ?
This is the right way... but you must wait the end of the installation.
The first step is for make a raspbian SDCard with the installation script in it and configured for start at boot (you are already done this step). Now the install start at the reboot.
You can see the progress with this ssh command :
if you are one a mac :
The new password of the pi is: moodeaudio
the result of the command is like that:
This is a long process depend of your raspberry and your internet connection. for me more than 2 hours on a rpi3 with all options on.
You must wait until the end for use it.
Good luck.
This is the right way... but you must wait the end of the installation.
The first step is for make a raspbian SDCard with the installation script in it and configured for start at boot (you are already done this step). Now the install start at the reboot.
You can see the progress with this ssh command :
Code:
ssh pi@moode "cat ~/mosbuild.log | grep 'COMPONENT\|STEP\| Compile \| END\| Error'"if you are one a mac :
Code:
ssh pi@moode.local "cat ~/mosbuild.log | grep 'COMPONENT\|STEP\| Compile \| END\| Error'"The new password of the pi is: moodeaudio
the result of the command is like that:
Code:
// STEP 2 - Expand the root partition to 3GB
// STEP 3A - Install core packages
// STEP 3B - Install core packages
// STEP 4 - Install enhanced networking
** Compile bluez-alsa
// STEP 5 - Install Rotary encoder driver
** Compile WiringPi
** Compile rotary encoder driver
// STEP 6 - Compile and install MPD
// STEP 7 - Create moOde runtime environment
// STEP 8 - Install moOde sources and configs
// STEP 9 - Alsaequal
// STEP 10 - Optionally squash /var/www
// STEP 11 - Optionally, install latest Linux Kernel
// STEP 12 - Launch and configure moOde!
// STEP 13 - Final prep for image
// COMPONENT 1 - MiniDLNA
// COMPONENT 2 - Auto-shuffle
// COMPONENT 3 - MPD Audio Scrobbler
// COMPONENT 4 - Shairport-sync
// COMPONENT 5 - Squeezelite
// COMPONENT 6 - Upmpdcli
** Compile Libupnp jfd5
** Compile Libupnpp
** Compile Upmpdcli
** Compile Upexplorer
// COMPONENT 7 - Optionally install gmusicapi
// COMPONENT 8 - Local UI display
// COMPONENT 9 - Allo Piano 2.1 Firmware
// ENDThis is a long process depend of your raspberry and your internet connection. for me more than 2 hours on a rpi3 with all options on.
You must wait until the end for use it.
Good luck.
Last edited:
Yes, it is very important to wait until the build process has finished, so HeeBoo's commands to monitor the log file are great.
And don't start configuring settings via the web interface until the build has finished, even if they are accessible before then, as any reboots at this stage will upset the build process and you will be left with unresponsive elements in the program. I speak from experience
Richard
I tried heeboo's modified script , to make sure i was patient enough I set it off and went out.Yes, it is very important to wait until the build process has finished, so HeeBoo's commands to monitor the log file are great.
And don't start configuring settings via the web interface until the build has finished, even if they are accessible before then, as any reboots at this stage will upset the build process and you will be left with unresponsive elements in the program. I speak from experience
Richard
It failed.. not because of the script but because of a down load error on a chrome bit.
When I got home and checked the log , on seeing the failure message, I simply swore at my home router , questioned my wife's lack of sympathy for my plight and then kicked of the script again and went to bed. In the morning joy was returned as this time the script had worked.
Patience is the key, just walk away.
Will just add that Tim publishing his build recipe has been most educational for this Windows guy and now feel confident in rebuilding various components myself, importantly compiling mpd.
Max Kellermann (the current developer of MPD) has been targeting commercial software/hardware vendors that have been using his code without complying with the licensing terms of the GPL. This has included Euphony Audio, Aurrender and SOtM, all of which charge big bucks (and Euros) for their products. I suspect he sees their GPL violations as particularly galling and so is chasing them up on their obligations when they distribute his hard work -- as he has every right to do.
More info on the saga can be found in the MPD list archives:
The mpd-devel December 2017 Archive by thread
I suspect that some other ostensibly free distributions of MPD are also not completely compliant with the GPL but the license has stricter terms for commercial distributions. I suppose the $10 "compulsory" donation that Tim instigated simply tipped moOde over the threshold and drew Max's attention, even though we all know it was a justifiably small gratuity to keep things running behind the scenes rather than a money making exercise.
Tim is obviously passionate about moOde and making it one of the best SBC-based music systems available. It is still being actively developed with new functionality being added on a daily basis, unlike some of the alternatives. He has done the right thing by Max K and others with the new FOSS model while still striving to give us what we want.
Just my opinion. Thanks for reading.
Richard
Last edited:
Hi Richard,
Good post. Copyright and license cannot be ignored and must be respected!
-Tim
Last edited:
If you get a failed step (as I did from a failed DNS lookup) restarting the script doesn't clear the log and so tailing or running your cat ~/mosbuild.log | grep 'COMPONENT\|STEP\| Compile \| END\| Error' gives spurious results.
Maybe once the build starts, clear the mosbuild.log every time?
For more security, i prefer say restart from the beginning and cross your fingers for no more DNS errors.
Good luck !
@Zootalaws
Or if the information in the previous mosbuild.log is worth preserving for some reason, add a file sequence number.
I went another direction here. Instead of "pulling" information from the moOde builder, I decided to try making the builder "push" it.
Try #1: use netcat (aka nc). I modified mosbuild.sh to include another option which, if accepted, asks for parameters NCHOST and NCPORT. Modified mosbuild_worker.sh to add a new function echoAll () which echoes to both stdout and to netcat $NCHOST $NCPORT. Edited any "echo" lines of interest in the script (in my case the lines HeeBoo greps for and some others) to "echoAll". Made a few changes in syntax to avoid problems.
How it's used: open a terminal on $NCHOST and invoke "nc -kl $NCPORT", e.g., start netcat as a port listener. Boot the moOde builder on the RPi. The same lines HeeBoo greps for will scroll in the monitoring terminal (while continuing to log to mosbuild.log on the RPi). Since netcat is already present by default in raspbian and pretty much all Linux distros I've used, this approaches requires no additional packages. A minor downside is that the port listener has to be killed manually when done. I suppose a clever bash script'er could fix this.
Try #2: use a true pub-sub framework---I chose to use MQTT. The mosquitto packages are available in pretty much all Linux distros but not installed by default. Now instead of a monitoring host and port, mosbuild.sh asks for the host running the pub-sub broker and for the pub-sub "topic". mosbuild_worker.sh was modified a bit more so it installs the mosquitto-clients package and echoAll () invokes mosquitto instead of netcat to publish to the broker and topic.
How it's used: start the broker on the chosen host if it isn't running. On some host, subscribe a mosquitto-client to the broker and topic. Boot the moOde builder on the RPi. The published lines scroll in the client. To a user, the result looks the same as try #1. In my case, the pub-sub framework is interesting for other reasons. For others, a downside to this approach is that one has to install a mosquitto server on some host and install a mosquitto client on the same or different host. On the upside, with addition of some tagging info in that echoAll () function, one could trivially simultaneously monitor multiple builds using a single client.
Try #3: expand on the pub-sub framework theme to send tweets, SMS, email. Since this requires breaking out of my LAN and typically involves money I wasn't interested but the current IOT mania has created lots of choices.
I'd love to hear of other solutions.
Regards,
Kent
PS - both these tries work across the multiple reboots.
Last edited:
If you want to monitor from another Linux machine, syslog must be a good way.
You could configure syslog from raspbian for local logging and remote logging and reconfigure syslog at the end of building on raspbian.