Stable: 2.5.2
Development: 2.6-alpha3
I am a long-time user of Music-on-Console, however have just installed it on my new laptop to find that M.O.C. fails to detect the audio driver, failing with the error message "FATAL_ERROR: No valid sound driver!". M.O.C. is the only application with this problem; Firefox, V.L.C., aplay, etc., all work perfectly with my plain A.L.S.A. set-up.
I am somewhat-surprised that M.O.C. has any difficulty detecting the speaker configuration, as it is fairly standard. Below is the output of aplay -L
(I want to output to PCH "default"):
My system is Gentoo x86_64 running kernel 4.19.86. M.O.C. was compiled with A.L.S.A. and F.L.A.C. support. Unfortunately, I cannot get any more verbose output from M.O.C., as running it when compiled with the "debug" flag leads to an instant segmentation fault.
Any help or a point in the right direction would be greatly appreciated; I really don't want to have to move to another music player.
Ashley.
jcf
Fri, 2019-12-06 04:26
Permalink
That's Odd
So are we.
That is also surprising. It's something we're also going to have to investigate as we may well need it to address your primary problem.
At this stage I'd usually suggest checking that you have all the required ALSA packages installed, but given that other applications are finding it I'm guessing they probably are.
Unfortunately, the Gentoo MOC package maintainer has not responded to us in the past. I will alert another knowledgable Gentoo user to see if he can help.
ashleydixon
Fri, 2019-12-06 05:35
Permalink
Regarding the segfault
Although I'm not knowledgeable enough with the code-base of M.O.C. to offer a patch, it seems the segfault is caused by the recursive call to
clone_popt_options
inmain.c
. Seems as though the arrayopts
array is overstepped when passed tomemcmp
. Trace:jcf
Fri, 2019-12-06 06:17
Permalink
I Think r2948 Is The Droid You're Looking For
I think this one is fixed in r2948 (also see Debian Bug#855125).
You mention offering a patch which makes me think you have the knowledge to apply that commit as a one-off patch and see if it helps. Contact mocmaint by e-mail if you can't get the patch from SVN.
ashleydixon
Fri, 2019-12-06 07:02
Permalink
Success... with the segfault
Applying the patch https://github.com/jonsafari/mocp/commit/156d79d80887a91aeb034e050197a953b3fe931a.diff to the current Gentoo/Portage release of M.O.C. does fix the segfault --- I'll commit this in a bit when I have a some time. Thanks for your help thus far.
Unfortunately, the original issue still remains.
Ashley.
tomaszg
Fri, 2019-12-06 13:16
Permalink
I'm using MOC on Gentoo with
I'm using MOC on Gentoo with plain ALSA setup on multiple machines. Now that you solved the segfault you could post more debug info about problem with ALSA - maybe the problem is just related to .asoundrc file or ALSADevice option in .moc/config? You can also look at http://moc.daper.net/node/2648 where problems with device names are discussed.
Also, if you managed to apply the patch, consider switching to current SVN code as it contains many fixes which didn't make it into released versions. Myself, I run my custom branch of MOC with many experimental changes, some of them related to ALSA. I don't think that they are relevant though, but you are free to try it if you feel adventurous: https://gitlab.com/tomaszg/mocp.
BTW. You can get some basic "debug" output even without debug USE flag just by running moc via "mocp -SF"
ashleydixon
Sat, 2019-12-07 11:43
Permalink
Your GitLab Distro Works Perfectly
I just cloned your GitLab repo and compiled it from source (I already had all the dependencies from emerge resolving them previously for the "official" Gentoo M.O.C.). It all works perfectly, as expected, meaning the version in the Gentoo repo is at fault here. I suppose this stops being a M.O.C. issue and becomes more of a Gentoo issue.
Ashley.
tomaszg
Sat, 2019-12-07 11:51
Permalink
It would be good if you would
It would be good if you would clone and check also official MOC repo and see if it also resolves your problem. Maybe Gentoo just needs a new MOC snapshot in portage.
Another possibility that comes to my mind is related to Allow24bitOutput MOC option which defaults to "no" for some obscure reason. Maybe your card just needs 24 bit mode to work. My code changed defaults in that respect.
ashleydixon
Sat, 2019-12-07 12:08
Permalink
Allow24bitOutput was the Culprit
I cloned the official M.O.C. repo and it didn't work. Passing Allow24bitOutput=yes makes it work fine though; thanks a lot for your help, seems as though your change was the fix. I've seen a lot of people on other forums complaining about the same error I had initially... maybe the Allow24bitOutput should be enabled by default in the *official* tree ? Seems weird not to, is there any reason to have it disabled by default ?
tomaszg
Sat, 2019-12-07 12:19
Permalink
I don't know of any reason, I
I don't know of any reason, I think it is old code and there was no good reason to change it, so conservative approach kept it the way it is.
Do you have any special soundcard, like USB DAC or something like that?
ashleydixon
Sat, 2019-12-07 13:21
Permalink
ALC283
Nothing particularly non-standard: Realtek ALC283.
ashleydixon
Sat, 2019-12-07 13:30
Permalink
Oh, apparently
Oh, apparently Allow24bitOutput was causing some issues with certain sound cards (see the NEWS file for version 2.4.2).
tomaszg
Sat, 2019-12-07 13:41
Permalink
Yeah, some undefined problem
Yeah, some undefined problem back in 2007 :) Well, I think that at least official version should have more verbose error reporting.
I still find it curious that your soundcard fails to work in 16-bit (or 8-bit) mode. From what I was able to understand about ALSA, it does its own mixing and resampling via "dmix", so it should by default accept a wide range of audio formats unless you explicitly ask to bypass it by using one of "hw:something" devices. Could you post part of "mocp -SF" identifying card capabilities? On my system it reports:
Or maybe you have something weird in your .asoundrc?
ashleydixon
Sat, 2019-12-07 14:26
Permalink
Cannot open mixers (although still works fine)
Output from
mocp -SF
below. Seems as though it is having some issues opening the P.C.M. and Master mixers./etc/asound.conf
Ashley.
tomaszg
Sat, 2019-12-07 14:43
Permalink
Mighty weird. Nothing
Mighty weird. Nothing suspicious here. Maybe the problem is rather related to lack of a mixer channel which would make it related to this commit. Not sure why Allow24bitOutput would fix it in official MOC.
ashleydixon
Sat, 2019-12-07 14:48
Permalink
Mixer not available ?
I'm not entirely sure why the mixer isn't available ? It is able to play audio, and other applications, such as
alsamixer
, seem to have no issues.Ashley.
tomaszg
Sat, 2019-12-07 14:51
Permalink
Maybe just the name of mixer
Maybe just the name of mixer channel is different. Does "amixer" show channels like "Master" and "PCM"?
ashleydixon
Sat, 2019-12-07 14:56
Permalink
Yeah, 'PCM', 'Master',
Yeah, 'PCM', 'Master', 'Headphone', etc., etc.
Everything you'd expect
tomaszg
Sat, 2019-12-07 18:57
Permalink
Seems that it is something
Seems that it is something jcf needs to look into and maybe pull some patches from my branch :)
jcf
Sat, 2019-12-07 19:01
Permalink
We Have A (Possible) Clue, Though
A recent problem gave me a clue, but fixing (and therefore confirming) it may require a non-trival reorganisation of MOC's ALSA sound driver with the potential to introduce more problems than bogus error message in a place few people look. That error message is part of a bigger picture.
jcf
Sat, 2019-12-07 18:58
Permalink
A Very Good Reason
The reason is a very good one: changing the default value may end up silently breaking MOC on more systems (where 24-bit is not supported) than it fixes. We just don't know how many that would be and therefore the safer approach is not to monkey with options which are more than merely user preferences.
However, I have now come up with a possible solution which we can check out.
ashleydixon
Sat, 2019-12-07 19:41
Permalink
I wonder if M.O.C. could
I wonder if M.O.C. could automatically query the sound card's capabilities to determine which option would be best ? Just a thought--- I might familiarise myself with the M.O.C. code-base over xmas when I have some time. I suppose it wholly depends on the quality of the A.L.S.A. A.P.I., which, I must confess, I know next-to-nothing nothing about.
tomaszg
Sat, 2019-12-07 19:46
Permalink
MOC does just that. The lines
MOC does just that. The lines from the log you posted show what was the result. Since apparently ALSA reported that it can work with 16-bit samples, it is difficult to guess what is the problem. It would be interesting to check in debug log what sound format was really chosen to play the audio. And compare that with results of official MOC code to see where the difference is.
jcf
Sat, 2019-12-07 20:23
Permalink
Something's Not Right
Having now looked at the appropriate portions of the code, it is obvious that something doesn't add up with what we have so far.
Could you please checkout a copy of the current HEAD (available from SVN or Git). Build and run it with the '
-D -O "Allow24bitOutput=no"
' command line options and, if it fails, post themocp_server_log
messages leading up to the failure. Then try that again with the options '-D -O "Allow24bitOutput=yes"
' and report that result.ashleydixon
Sat, 2019-12-07 21:03
Permalink
The current HEAD from the Git
The current HEAD from the Git works in neither situation.
Disallowing 24-bit:
And allowing 24-bit:
ashleydixon
Sat, 2019-12-07 21:05
Permalink
Correction
Sorry, the below is the correct log when allowing 24-bit output.
tomaszg
Sat, 2019-12-07 21:13
Permalink
Ah, now it makes sense. I don
Ah, now it makes sense. I don't know why it can't open mixer channel but my guess is that you need something like
in your .asoundrc. MOC was probably trying to access mixer on a different card, which was HDMI and didn't probably have volume control.
I still however believe that it is a bug in MOC as MOC should work even when no mixer controls are available. This behaviour was changed in my fork and that's the reason that you got it to work.
I wonder if MOC should also try somehow to access correct mixer channels on other card, maybe something is wrong in alsa.c. I don't know if ALSA API allows for that though.
ashleydixon
Sat, 2019-12-07 21:19
Permalink
Yes, adding defaults.ctl.card
Yes, adding
defaults.ctl.card 1
to the asound file seems to fix it.From what I remember (and this is from many years ago), the official M.O.C. used to allow you to open it without available mixer controls, did it not ? Or maybe I'm just imagining things...