tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: mixerctl with no args



    Date:        Thu, 23 Feb 2017 10:35:59 +0200
    From:        Andreas Gustafsson <gson%gson.org@localhost>
    Message-ID:  <22702.40687.501826.594774%guava.gson.org@localhost>

  | The criterion for skipping the tests should be "no audio", not
  | "running under qemu"

I totally agree, and if you know a rational way that a shell script
(which is what the test is) can determine "no audio" I'll happily
change it that way.

Maybe sysctl can help?   Doesn't look like it though, the only sign
of audio I can see is in kern.drivers, but the presence of audio there
(which I'd expect in any generic) doesn't actually mean any audio device
(or pseudo-device) exists.

Does anyone have any suggestions?

That is, apart from trying audioctl or mixerctl ... using those (and
expecting them to work) in a test designed to determine if they work
is not rational.

  | - otherwise they will still fail on real hardware that lacks audio devices.

I don't think that's really a big problem.  Sure, they will fail then, but
whoever is running the tests then presumably looks at the results, sees it
is an audio related test that failed, thinks "this system doesn't have audio",
and simply ignores the failure.

  | I think mixerctl should be fixed, at least for the case where there
  | are no arguments.

I agree, and I'll fix it.

  | I don't have an opinion on the "mixerctl -d /dev/mixer2" case.

For now (in the sources I have already updated on the assumption
that this would be the outcome -- but I can still just not commit it
if there are opposing opinions), that will give a usage message, regardless
of what device is specified (either -a, or a pattern, is required.)

I could change it to try the open first if -d was given (regardless of
any other bad usage) if opinions is that that would be a good idea.

  | Looks like the problem doesn't occur on amd64 because it has
  | "pseudo-device pad" in GENERIC.

Yes, I saw that.   That's why I added the i386 test.   It looks as if
the sparc qemu has some kind of real audio device configured (though I
have no idea where the sound goes...)

  | I wonder why i386 doesn't.

Paul Goyette wondered the same (in a non-list message).

Beats me...   if someone decides adding it would be a good idea, please
hold off for a day, so we can test the mixerctl changes on a b5 system
without any audio.

kre




Home | Main Index | Thread Index | Old Index