Ok,
Got frustrated pulled the power plug and rebooted.
Had a win, found alsamixer, unmuted, saved with the alsactl command, reboot. Putty wouldn't find again, pulled the plug, turned back on.
Mute stuck.
Will not do the other buffer etc changes and see.
Will go from there.....
OLD: mpdPup - Simplified MPD Music Server/Jukebox - v0.9.2
I'm not sure how long you're waiting when you reboot and then give up and pull the power - the Alix is a very low power system, so if you're saving changes a safe/clean reboot can sometimes take a while, it's best to be patient.
It sounds like the Wave was in some bad hardware state when you reported those alsamixer errors - sometimes just plugging/unplugging the card is enough to clear that sort of issue, though unplugging everything as you did will work too.
Here's a more brute force solution to unmute the card during bootup - this is essentially what the diyaudio user Ensen did, but I've modified the approach to cover any cards which may be installed.
Type the following at the command line:
Then paste the following into the editor:
press ctrl-x to exit, then y to save the script.
Lastly type this command:
Reboot to save the config, and give it a good 5-10 minutes or so before yanking any plugs to give it time to do whatever it's trying to do and make sure the changes stick.
After that the cards should be unmuted as part of the boot process no matter what state they decided to boot up in on their own.
It sounds like the Wave was in some bad hardware state when you reported those alsamixer errors - sometimes just plugging/unplugging the card is enough to clear that sort of issue, though unplugging everything as you did will work too.
Here's a more brute force solution to unmute the card during bootup - this is essentially what the diyaudio user Ensen did, but I've modified the approach to cover any cards which may be installed.
Type the following at the command line:
Code: Select all
nano /etc/init.d/unmuteCode: Select all
#!/bin/sh
unmute_audio(){
CARDS=`aplay -l | grep card | cut -f 1 -d ':' | uniq | cut -f 2 -d ' '`
for card in $CARDS
do
CONTROLS=`amixer -c $card scontrols | cut -f 2 -d "'"`
for control in $CONTROLS
do
amixer -c $card sset $control unmute >/dev/null 2>/dev/null
amixer -c $card sset $control 100% >/dev/null 2>/dev/null
done
done
}
unmute_audio
Lastly type this command:
Code: Select all
chmod +x /etc/init.d/unmuteAfter that the cards should be unmuted as part of the boot process no matter what state they decided to boot up in on their own.
Hey Idolse,
Had waited a good ten minutes, this was initial boot after wizards, anyway seems ok, will power up again later, this should see if unmute stiluck with the alsactl command.
Will then add your script and reboot and go from there.
Walter I'm looking forward to powersupplies as on the AudioCircle thread with Alix/voyage the powersupply to the Alix made a major difference. Going to run and see how it goes, make my own as a linear non regulated to start and compare to a SMPS. Curiosity here. And bypass the input jack.
Ahh the joys!
Had waited a good ten minutes, this was initial boot after wizards, anyway seems ok, will power up again later, this should see if unmute stiluck with the alsactl command.
Will then add your script and reboot and go from there.
Walter I'm looking forward to powersupplies as on the AudioCircle thread with Alix/voyage the powersupply to the Alix made a major difference. Going to run and see how it goes, make my own as a linear non regulated to start and compare to a SMPS. Curiosity here. And bypass the input jack.
Ahh the joys!
Ok - I did put a note about this on the first page of this thread, but I see I'm going to have to make it clearer - the Alix boards are extremely low/under powered - plenty of power for MPD, but not that much power for many other types of activity. After the very first reboot Puppy Linux goes through a stage where it optimizes its' file system. This is a one time event, but on a low powered device it can take forever (10-30 minutes based on the system and CF card speed) and the system is unresponsive all this time. The good news is this is a one time event, but if you unplug the system while it's doing it I have no idea what sort of state you would leave it in (i.e. this could be the source of all your troubles) - you really need to be patient for that initial reboot and let it do it's thing - go out for dinner or a lunch break or something after you run through the wizard and reboot.
Not sure how I can better warn Alix users - if anyone with an Alix board has an idea let me know - if there is something in dmesg or something else I can check from a BASH script to know it's an Alix board I can pop up a better warning to Alix/Soekris users that the initial reboot will take a really long time.
Not sure how I can better warn Alix users - if anyone with an Alix board has an idea let me know - if there is something in dmesg or something else I can check from a BASH script to know it's an Alix board I can pop up a better warning to Alix/Soekris users that the initial reboot will take a really long time.
I think I see a way to determine the motherboard so I can be a bit more informative for the user. Need the help of the Alix users here - log into your system and copy the output of the following command to a text file:It's a lot of text, so please try to avoid just pasting it into a post--the board system should let you attach it--anyway manufacturer information is in there, so I should be able to leverage that, I just want to see what it's reporting so I can modify the scripts to trigger off of it and warn the user about the reboot time.
Code: Select all
dmidecode -t 1,2,3,4,5
hey Idolse,
Good break this time, put the boy to bed and washing up and fed dog and finished washing up and put wife to bed and taadaaah, Loaded!
ok.....
VESA BIOS Extensions not detected.
VESA BIOS Extensions not detected.
# dmidecode -t 1,2,3,4,5
# dmidecode 2.9
# No SMBIOS nor DMI entry point found, sorry.
#
and that was all it wrote.
Believe these have a tinyBios, perhaps just a final screen in the wizard regardless of board type, wait minimum of 10 mins and if you cant login yet.......just wait longer!
Not sure if the reference to Ace Ventura is going to be missed or not....
Currently the mute edit is sticking, I will add in the extra bit you sent, shall unmute first. Then will know if it is actually unmuting on boot.
Thanks Idolse,
Good break this time, put the boy to bed and washing up and fed dog and finished washing up and put wife to bed and taadaaah, Loaded!
ok.....
VESA BIOS Extensions not detected.
VESA BIOS Extensions not detected.
# dmidecode -t 1,2,3,4,5
# dmidecode 2.9
# No SMBIOS nor DMI entry point found, sorry.
#
and that was all it wrote.
Believe these have a tinyBios, perhaps just a final screen in the wizard regardless of board type, wait minimum of 10 mins and if you cant login yet.......just wait longer!
Not sure if the reference to Ace Ventura is going to be missed or not....
Currently the mute edit is sticking, I will add in the extra bit you sent, shall unmute first. Then will know if it is actually unmuting on boot.
Thanks Idolse,
Last edited by PET-240 on Mon 11 Jun 2012, 13:44, edited 1 time in total.
Ok, seems alright, the code you sent I couldn't paste so I had to copy by typing, however it was still muted on reboot, so to be sure, I did power off, waited 10, then unplugged, rebooted and waited 10, logged in and still muted.
So unmuted and resaved as per the alsactl command.
The coverart isn't working for me, see if the pics load, you may see something I'm missing......
http://db.tt/pfGlCQuE
http://db.tt/9jUwJ10F
http://db.tt/tojXVJHZ
Sorry for the links, couldn't figure another way with iPad......
If I can copy and paste the code you sent, how I wrote it, or whether I need to save to notepad or something first?
So unmuted and resaved as per the alsactl command.
The coverart isn't working for me, see if the pics load, you may see something I'm missing......
http://db.tt/pfGlCQuE
http://db.tt/9jUwJ10F
http://db.tt/tojXVJHZ
Sorry for the links, couldn't figure another way with iPad......
If I can copy and paste the code you sent, how I wrote it, or whether I need to save to notepad or something first?
Figured I could just type the first line again.
How'd I do?
Thanks for all the support Idolse!
Code: Select all
#!/bin/sh
unmute_audio(){
CARDS=`aplay -l | grep card | cut -f 1 -d ':' | uniq | cut -f 2 -d ' '`
for card in $CARDS
do
CONTROLS=`amixer -c $card scontrols | cut -f 2 -d "'"`
for control in $CONTROLS
do
amixer -c $card sset $control unmute >/dev/null 2>/dev/null
amixer -c $card sset $control 100% >dev/null 2>/dev/null
done
done
}
unmute_audio
Thanks for all the support Idolse!
Hopefully tomorrow then, my beauty sleep is calling......
Thanks for all the assist Idolse, been fantastic support, realise I am a little difficult not knowing much, but the upside is if I can break it......I probably will.
Will be getting this out and about here once I've got it up and going reliable, and thats no reflection on you or mpdpup, just me, new at this coding, will get it eventually!
Patience is a virtue.........pity it takes so long.
Thanks Again!
Thanks for all the assist Idolse, been fantastic support, realise I am a little difficult not knowing much, but the upside is if I can break it......I probably will.
Will be getting this out and about here once I've got it up and going reliable, and thats no reflection on you or mpdpup, just me, new at this coding, will get it eventually!
Patience is a virtue.........pity it takes so long.
Thanks Again!
Boot speed on Alix
Idolse
I just timed a boot up. From power on to a successful GMPC connection was 65 seconds on my ALIX. Coming from a Windows world that seems lightning fast!.. I have to expect it also depends on speed of CF. Mine is nothing special a x133 Kingston CF.
Walter
I just timed a boot up. From power on to a successful GMPC connection was 65 seconds on my ALIX. Coming from a Windows world that seems lightning fast!.. I have to expect it also depends on speed of CF. Mine is nothing special a x133 Kingston CF.
Walter
Alix and Alsa settings
Hi Idolse, Walter and others,
Idolse wow you did a fantastic job, mpdPup is great!! For me Linux is new, but mpdpup works like a charm! So here is some, very positive, feedback.
Like Walter, i'm coming from CMP2, a dedicated and stripped to the bone (hardware and OS wise) Windows XP based musicplayer, Atom-based in my case. Which gives very good SQ. I learned about the big impact of changes in hardware and OS on SQ. Because XP is getting old, i figured to try and learn linux which is the future for diy music playback.
So this is my setup.
NAS -> Alix 3D3 -> WaveIO -> spdif coax cable (I2S in future) -> modded Benchmark DAC1 -> Hypex-based class D amp -> PMC OB1
Alix 3D3 has battery PSU (12v SLA). This version has monitor (which is only used when changing bios settings) and Award-Bios. In bios CPU-speed is set to 400 MHz (much better SQ than @500MHz), sound and IDE (yes!) are disabled, so no CF (which gives better SQ).
Mpdpup is started from USB stick, which i remove after start up (again a step up in SQ).
The WaveIO has its own 12v SLA battery and lowdrop regulator (to 5v).
WaveIO mute at startup is solved perfectly by Idolses advice to store it somewhere in the startup-sequence.
At first sound was a bit flat and i almost decided to go back to CMP2, despite of the great comfort of pmdPup, when i read Waters suggestions for Alsa-settings (audio out). This fired up SQ, and i experimented a bit. These are my favorite settings:
period_time "8192"
buffer_time "131072"
Before the Audio out lines i put:
- audio_buffer_size "90000" (i thought mdpup takes 128MB of the RAM, so to be safe i chose 90MB for putting files in RAM)
- buffer_before_play "10%" (when choosing 100% it takes ages to load the file into RAM.
The rest is the same as Walter found out (except for fragment_size which i think is not an ALSA parameter, see the article mentioned below).
I found this articles on period/buffer/fragment times etc.
http://0pointer.de/blog/projects/pulse-glitch-free.html
http://linux.die.net/man/5/mpd.conf
Conclusion for me was i had to find the optimum within:
- period_time as large as possible
- buffer_time as small as possible
- period_time * 16 = buffer_time (i learned from walters article)
So i experimented with the following settings, and chose semi-binary time-periods (2x2x2x2xetc). a bit foolish of course because period are about microseconds and not bits. Whatever, just doing the best i can. These are the settings i tried:
period_time / buffer_time
65536 / 1048576
32768 / 524288
8192 / 131072
4096 / 65536
For me 8192 / 131072 gave best sound and deepest and broadest sound stage.
Again: thanks a lot Idolse, this is great, and a best first step into Linux!!
About upsampling: with Alix this is impossible. I will try mpdpup on my Atom-board (but cannot connect it to LAN, maybe drivers, will try again later).
My Benchmark DAC1 does internal up sampling to 172.400. Optimum in my setup, SQ-wise, is to feed the DAC with 88.200 signal.
My solution is to use a desktop PC and SoX batch converter to convert the files from 16 bits / 44.100 to 32 bits / 88.200 and put the files in a special folder on the NAS (32 bits sound better than 24 bits, i think maybe because 32 bits is native for pc). In this way i can play 32/88.200 files on the Alix.
I hope this adds to the development of mpdpup. CMP2 learned me how important it is to have a small and light OS. So as far as i am concerned, i would not prefer more features or functionality. Less is more...
Best regards,
Douwe
Idolse wow you did a fantastic job, mpdPup is great!! For me Linux is new, but mpdpup works like a charm! So here is some, very positive, feedback.
Like Walter, i'm coming from CMP2, a dedicated and stripped to the bone (hardware and OS wise) Windows XP based musicplayer, Atom-based in my case. Which gives very good SQ. I learned about the big impact of changes in hardware and OS on SQ. Because XP is getting old, i figured to try and learn linux which is the future for diy music playback.
So this is my setup.
NAS -> Alix 3D3 -> WaveIO -> spdif coax cable (I2S in future) -> modded Benchmark DAC1 -> Hypex-based class D amp -> PMC OB1
Alix 3D3 has battery PSU (12v SLA). This version has monitor (which is only used when changing bios settings) and Award-Bios. In bios CPU-speed is set to 400 MHz (much better SQ than @500MHz), sound and IDE (yes!) are disabled, so no CF (which gives better SQ).
Mpdpup is started from USB stick, which i remove after start up (again a step up in SQ).
The WaveIO has its own 12v SLA battery and lowdrop regulator (to 5v).
WaveIO mute at startup is solved perfectly by Idolses advice to store it somewhere in the startup-sequence.
At first sound was a bit flat and i almost decided to go back to CMP2, despite of the great comfort of pmdPup, when i read Waters suggestions for Alsa-settings (audio out). This fired up SQ, and i experimented a bit. These are my favorite settings:
period_time "8192"
buffer_time "131072"
Before the Audio out lines i put:
- audio_buffer_size "90000" (i thought mdpup takes 128MB of the RAM, so to be safe i chose 90MB for putting files in RAM)
- buffer_before_play "10%" (when choosing 100% it takes ages to load the file into RAM.
The rest is the same as Walter found out (except for fragment_size which i think is not an ALSA parameter, see the article mentioned below).
I found this articles on period/buffer/fragment times etc.
http://0pointer.de/blog/projects/pulse-glitch-free.html
http://linux.die.net/man/5/mpd.conf
Conclusion for me was i had to find the optimum within:
- period_time as large as possible
- buffer_time as small as possible
- period_time * 16 = buffer_time (i learned from walters article)
So i experimented with the following settings, and chose semi-binary time-periods (2x2x2x2xetc). a bit foolish of course because period are about microseconds and not bits. Whatever, just doing the best i can. These are the settings i tried:
period_time / buffer_time
65536 / 1048576
32768 / 524288
8192 / 131072
4096 / 65536
For me 8192 / 131072 gave best sound and deepest and broadest sound stage.
Again: thanks a lot Idolse, this is great, and a best first step into Linux!!
About upsampling: with Alix this is impossible. I will try mpdpup on my Atom-board (but cannot connect it to LAN, maybe drivers, will try again later).
My Benchmark DAC1 does internal up sampling to 172.400. Optimum in my setup, SQ-wise, is to feed the DAC with 88.200 signal.
My solution is to use a desktop PC and SoX batch converter to convert the files from 16 bits / 44.100 to 32 bits / 88.200 and put the files in a special folder on the NAS (32 bits sound better than 24 bits, i think maybe because 32 bits is native for pc). In this way i can play 32/88.200 files on the Alix.
I hope this adds to the development of mpdpup. CMP2 learned me how important it is to have a small and light OS. So as far as i am concerned, i would not prefer more features or functionality. Less is more...
Best regards,
Douwe
Hi Douwe,
Awesome feedback, thanks! You've definitely taken the tweaking up a notch. I never thought about disabling IDE and yanking the USB stick after bootup when I was choosing/configuring Puppy Linux this way, but that's a very cool way to go.
Regarding memory, mpdPup would only take a few megabytes more than the ISO size - so it's probably more like 70MB with the current release.
In terms of futures, while I plan on adding functionality, I don't envision any more services being enabled by default other than what's enabled in the current release. Additional functionality which requires some sort of daemon will almost always be added as an opt-in. So basically the only impact would be a slight increase in the iso size - then next release will go up by ~10MB, but basic default processes will remain identical. Even though that release will go up I'm not done with size optimizations - I fully expect future releases to go down again as I re-review the included packages and go through more rounds of optimization.
I have been thinking about an option for hardcore tuners like yourself where you can install mpdPup on two systems - one system running nothing but MPD itself, and the other running all the remote control clients/daemons. This can be done manually today of course, but curious if there would be much demand for automating it.
I'm seeing similar results with Walter's settings, and will test your suggestions. When I first started working on this project I had moved overseas and my stereo didn't come with me - I'd been more focused on the overall OS and hadn't spent too much time on the audio tuning. it's only recently I've put together a new stereo and been able to evaluate more subtle changes. - I see now that there is a lot that can be improved here.
I definitely plan on adding the ability to tweak these buffer/sound settings through the wizards - I'm on the fence regarding whether they should be enabled by default, as I'm not sure the same settings can be used universally across all sound devices. I've been thinking it would be nice to somehow crowd-source the best settings - in the future I want to add an ABX testing script from here, that's just a basic framework, it will need a lot more expansion for user friendliness. It would be very cool if people could tweak settings, test via ABX, and then upload the results somewhere - a common set of winning settings could theoretically be determined. I'll need to think on that but guessing it's not something I'll be able to accomplish any time soon.
I haven't read any glowing reviews of upsampling with libsamplerate, but if you try it out let me know how it goes - although it's included I haven't played with it. Ecasound & Brutefir are other things I've considered adding - mpd can pipe to these applications to leverage a different playback engine. No guarantees though, a lot of that will depend on how easily they can be added to the wizards and whether they'll support sample rate switching.
Awesome feedback, thanks! You've definitely taken the tweaking up a notch. I never thought about disabling IDE and yanking the USB stick after bootup when I was choosing/configuring Puppy Linux this way, but that's a very cool way to go.
Regarding memory, mpdPup would only take a few megabytes more than the ISO size - so it's probably more like 70MB with the current release.
In terms of futures, while I plan on adding functionality, I don't envision any more services being enabled by default other than what's enabled in the current release. Additional functionality which requires some sort of daemon will almost always be added as an opt-in. So basically the only impact would be a slight increase in the iso size - then next release will go up by ~10MB, but basic default processes will remain identical. Even though that release will go up I'm not done with size optimizations - I fully expect future releases to go down again as I re-review the included packages and go through more rounds of optimization.
I have been thinking about an option for hardcore tuners like yourself where you can install mpdPup on two systems - one system running nothing but MPD itself, and the other running all the remote control clients/daemons. This can be done manually today of course, but curious if there would be much demand for automating it.
I'm seeing similar results with Walter's settings, and will test your suggestions. When I first started working on this project I had moved overseas and my stereo didn't come with me - I'd been more focused on the overall OS and hadn't spent too much time on the audio tuning. it's only recently I've put together a new stereo and been able to evaluate more subtle changes. - I see now that there is a lot that can be improved here.
I definitely plan on adding the ability to tweak these buffer/sound settings through the wizards - I'm on the fence regarding whether they should be enabled by default, as I'm not sure the same settings can be used universally across all sound devices. I've been thinking it would be nice to somehow crowd-source the best settings - in the future I want to add an ABX testing script from here, that's just a basic framework, it will need a lot more expansion for user friendliness. It would be very cool if people could tweak settings, test via ABX, and then upload the results somewhere - a common set of winning settings could theoretically be determined. I'll need to think on that but guessing it's not something I'll be able to accomplish any time soon.
I haven't read any glowing reviews of upsampling with libsamplerate, but if you try it out let me know how it goes - although it's included I haven't played with it. Ecasound & Brutefir are other things I've considered adding - mpd can pipe to these applications to leverage a different playback engine. No guarantees though, a lot of that will depend on how easily they can be added to the wizards and whether they'll support sample rate switching.
Buffer tuning
Douwe
Awesome input. I was hoping to spawn a little community of interest around MPD on embedded processors as we had in CMP. The sound quality opportunities are unbelieveable, and the linux platform is designed to facilitate this level of control. In XP we were hacking and up against the limitations of the architecture os the core OS.
You have moved the bar forward. I am excited to get home and apply your buffer settings.
Also intrigued about the Bios settings. I do not have video support as I went even more minimalist with the 3D2 Alix. I'll have to figure out how to set up a console so I can get into the bios. ??? I have a null cable (db9 connector) cable, just not sure what I attach it to?!?!?
Idolse, I am also glad to hear that I am not imagining the SQ pop that comes with these settings. I think it is a tribute to your low latency platform that we can take SQ up a notch. I could imagine that over time a wizzard that has 2 options, basic to be followed by 90% of the crowd, and an advanced branch that allows toggling of the buffer settings could strike the ideal balance of ease and flexibility. On the other hand, the advanced user can just edit the conf files. I have chosen to keep a copy of these on my NAS. This way if I need to involke the wizzard for any reason to get me back to a base mpdpup I can just pop mpd.conf back in from the NAS to get back to full tweak.
Awesome input. I was hoping to spawn a little community of interest around MPD on embedded processors as we had in CMP. The sound quality opportunities are unbelieveable, and the linux platform is designed to facilitate this level of control. In XP we were hacking and up against the limitations of the architecture os the core OS.
You have moved the bar forward. I am excited to get home and apply your buffer settings.
Also intrigued about the Bios settings. I do not have video support as I went even more minimalist with the 3D2 Alix. I'll have to figure out how to set up a console so I can get into the bios. ??? I have a null cable (db9 connector) cable, just not sure what I attach it to?!?!?
Idolse, I am also glad to hear that I am not imagining the SQ pop that comes with these settings. I think it is a tribute to your low latency platform that we can take SQ up a notch. I could imagine that over time a wizzard that has 2 options, basic to be followed by 90% of the crowd, and an advanced branch that allows toggling of the buffer settings could strike the ideal balance of ease and flexibility. On the other hand, the advanced user can just edit the conf files. I have chosen to keep a copy of these on my NAS. This way if I need to involke the wizzard for any reason to get me back to a base mpdpup I can just pop mpd.conf back in from the NAS to get back to full tweak.
Re: Buffer tuning
I'm guessing you mean you're not sure where to attach it to on your PC - modern PCs don't come with Serial/DB9 connectors, you need to purchase a USB-to-Serial adapter if you want to mess with the console.wlowes wrote:Also intrigued about the Bios settings. I do not have video support as I went even more minimalist with the 3D2 Alix. I'll have to figure out how to set up a console so I can get into the bios. ??? I have a null cable (db9 connector) cable, just not sure what I attach it to?!?!?
I haven't A/B'd this enough to determine whether it's psycho-acoustics, and another problem is that I just swapped my speaker stands for a 3" shorter pair and that by itself is making a huge difference, but I do think I hear something - I may integrate a basic version of the ABX script just to verify I'm not crazy. Anyway my thoughts are running pretty similarly around an advanced vs. basic Wizard. Part my reasoning to implement it is actually selfishness - even though I'm technical enough to change things on my own I've come to appreciate the laziness the wizards give me - I don't like making changes I know the wizards will blow away.wlowes wrote:ldolse, I am also glad to hear that I am not imagining the SQ pop that comes with these settings. I think it is a tribute to your low latency platform that we can take SQ up a notch. I could imagine that over time a wizzard that has 2 options, basic to be followed by 90% of the crowd, and an advanced branch that allows toggling of the buffer settings could strike the ideal balance of ease and flexibility. On the other hand, the advanced user can just edit the conf files. I have chosen to keep a copy of these on my NAS. This way if I need to involke the wizzard for any reason to get me back to a base mpdpup I can just pop mpd.conf back in from the NAS to get back to full tweak.