Date:Thu, 23 Feb 2017 12:39:24 +0200
From:Andreas Gustafsson
Message-ID: <22702.48092.78965.364...@guava.gson.org>
| I suppose this is possible, but I think such cases would be rare enough
| that there is no harm in skipping the tests on those.
Sounds reasonable.
Robert Elz wrote:
> | (/dev/null
>
> Is it guaranteed that audio0 exists if any audio does? Including
> with kernel configs that wire down devices to specific hardware?
> That is, is it possible that audio1 might exist when audio0 doesn't?
I suppose this is possible, but I think such cases
Date:Thu, 23 Feb 2017 12:01:05 +0200
From:Andreas Gustafsson
Message-ID: <22702.45793.582015.94...@guava.gson.org>
| How about the following command?
| (/dev/null
Is it guaranteed that audio0 exists if any audio does? Including
with kernel configs that wire d
On Thu, Feb 23, 2017 at 05:05:07PM +0700, Robert Elz wrote:
> Is this new with the in-kernel audio mixer ?
Yes, but Andreas' suggestion sounds even simpler.
Martin
Date:Thu, 23 Feb 2017 10:43:08 +0100
From:Martin Husemann
Message-ID: <20170223094308.gb10...@mail.duskware.de>
| Not sure this is good, but you get
|hw.${audioif}.{frequency,precision,channels}
Is this new with the in-kernel audio mixer ?
If so that would e
Robert Elz wrote:
> 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.
How about the following command?
(/dev/null
This should yield a zero exit status iff /dev/audio0 can be opened
for r
On Thu, Feb 23, 2017 at 04:34:40PM +0700, Robert Elz wrote:
> 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)
Date:Thu, 23 Feb 2017 10:35:59 +0200
From:Andreas Gustafsson
Message-ID: <22702.40687.501826.594...@guava.gson.org>
| 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 shel
Robert Elz wrote:
> I noticed that the b5 mixerctl tests fail - seems to be because the
> qemu kernel the tests are run under has no audio (and hence any open
> of /dev/mixer* fails). That's fine, and I can (and am in the process
> of) cause the tests that will fail to simply be skipped when runn
I noticed that the b5 mixerctl tests fail - seems to be because the
qemu kernel the tests are run under has no audio (and hence any open
of /dev/mixer* fails). That's fine, and I can (and am in the process
of) cause the tests that will fail to simply be skipped when running
under qemu.
But one o
10 matches
Mail list logo
