I have one nfs mount as my music collection. Configured it through the gui, everything default. At shutdown or reboot, I get a stop job for the nfs service so it takes 90s to shutdown.
Running:
volumio-2.063-2017-02-06-odroidc2.img.zip
I don’t see this on my C2, but I haven’t tried viewing it directly connected to a monitor. Is there any other info there, or does it just say “stop job?”
Does nfs path contain some special characters, like space?
There have been few fixes in last few days to address several issues related to paths & special characters, making shares-related operations more reliable.
Is Volumio on wifi?
There could also be a tricky issue with systemd & dbus during shutdown, showing up particularly with wireless network: at shutdown systemd apparently kills wifi network before unmounting nfs shares (and cifs, etc), resulting in shutdown waiting (long time) for a timeout.
I read sth on Archlinux some time ago about this with some suggested workaround: logged it at some point within a wpa_supplicant related commit on Github to look at.
(BTW another option for records).
We could reopen this specific issue if the recent fixes in upcoming release do not fix this case.
Strange, I posted a reply a couple of days ago but it is gone.
In the mean time I think I now what the problem is. The nfs path is clean, no spaces and I use ethernet only.
I added a second nfs folder in the media library and I was playing a file from that second folder when initiating a shutdown from the gui.
I did not get a stop job from my first share, only from the second one. So It looks like volumio keeps a lock on the playing file during unmounting of the nfs shares.
Interesting.
Do you still have the issue on a new 2.114 image? (assuming you may build your own)
Thanks, I’ll try it. Could you point me to the overview site of these updates? The updates.volumio.org/odroidc2/volumio/2.118/ is not accessible.
You can get the latest version from the download page, it is an official release.
Note that the ODROIDDAC2 volume issue has not been resolved by HK. We can’t stop the amplifier gain ourselves, so no change.
O ok, sorry did not notice that.
Just tested it and NFS bug is still present, stop job for both nfs shares at shutdown.
Yes, I also noticed that. Volume issue is not fixed in this release, it even became worse. Seems this release has the same changes as I suggested here:
forum.odroid.com/viewtopic.php?f … 15#p181721
by using:
static const DECLARE_TLV_DB_SCALE(digital_tlv, -12750, 50, 1);
But that only changes the scale and and not the output.
Now alsamixer says it is 0dB at 100% but output is still +24dB at 100%.
It looks like the hifiberry guys solved it over here but not sure how safe it is:
github.com/respeaker/lede/blob/ … h-Hi.patch
They are using snd_soc_limit_volume
I am a bit hesitant to use this DAC at the moment, if some program would set the alsa volume to 100% while my amplifier’s volume is > 25%, I think I can probably throw away my speakers. So I might return the DAC if it is not solved real soon because it’s an atom bomb in disguise. Not suitable for consumer use in its present state.
Additionally I cannot find any application of using +24dB on a DAC, do you happen to know where it is used for?
Yes, I’m aware of how others (not only Hifberry people) solved it for a pcm512x, also Allo did it for the Piano in a nearly identical way.
HK’s driver is not their own development, it is amlogic’s and therefore not sure if a function “snd_snd_soc_limit_volume” to limit HW gain could be added properly…
Doubt whether this is going to be solved soon, unfortunately it renders volume control via Volumio useless.
And you are absolutely right, I do not see the purpose of +24dB either, perhaps TI had a reason.
Btw. I can’t believe the release became worse, I reverted the kernel change after discovering it did not work and I never experimented with scaling.
Aha thanks for getting me up to speed, this issue goes back some time I see.
Could the future new mainline kernel solve this issue?
I read some more on pro and consumer audio the last hour and I now wonder, does the distortion at +24dB occur at the output of the DAC or does it happen within the amplifier. It occurred to me that it might be possible that if you connect the dac to professional gear there will be no distortion. If that would be the case, it might be possible to buy some converter from pro audio to consumer audio and set the dac to +24dB.
Just now, in the new/latest release I set alsamixer to 100% and it says 0dB. Not sure what alsamixer said in the previous release. With worse I mean, it now looks like it’s good (in alsamixer, my first thought was it was fixed, only read your post after that) but nothing changed. Output did not become worse (or better, just the same).
Seems there are converters (for pro to consumer and vice versa) but I cannot find RCA to RCA. It seems the +24dB (or +4dBU) is connected to a XLR connector and +0dB (-10dBU) is connected to RCA. So you would have buy a RCA to XLR connector converter and then this audio convertor:
amazon.com/Rolls-MB15b-MB15 … B0002IL4B4
Or hardkernel just could limit RCA outputs to 0dB which is standard?
This dac limit thing consumes a lot of my odroid time, pfff. First gonna check the systemd logs tomorrow before commenting. Had a lot of nfs bugs on my debian stable desktop since systemd so I think I can debug this one too.
I had a look at the Hifiberry solution and apparently IQAudio is doing something very similar.
Not sure about it yet, but I think it is worth a try. I’ll let you know.
NOTE: Discussion re. volume level should be continued here: https://volumio.org/forum/volumio-118-odroid-volume-problem-t6076.html
Back to the OP issue: i have tested it now with an nfs share to a Synology NAS and do not have this issue.
I can play something and shut down in the middle, no delay.
But this needs to be looked into further, because I have seen the problem while indexing the library with cifs.
More to follow…
@gkkpch
While you do some related investigations, you may want to check also the wifi scenario mentioned here: I’m on nfs, and got similar shutdown delays at some points.
I need to test again, but I find that track rather convincing (while is not the actual case of OP): there might be different causes which fall into same “delayed shutdown” bucket.
I get the same NFS problem during the shutdown process as well, at version 2.130 (Mon Mar 27 21:08:47 CEST 2017).
I temporary get arround this by using following commands:
echo volumio | sudo -S cp /etc/systemd/system/multi-user.target.wants/wireless.service /etc/systemd/system
sudo sed -i -e '/^Before=/s/$/ remote-fs.target/' /etc/systemd/system/wireless.service
sudo systemctl disable wireless.service
sudo systemctl enable wireless.service