> At Tue, 4 Jan 2005 13:25:40 -0600,
> [email protected] wrote:
> > [snip - how to get to the problem]
> > At this point, I get the window asking if I heard the sound (I did
not). If
> > I repeat the test after waiting a short period, it eventually succeeds.
>
> The default blocking behavior of OSS devices was changed recently.
> When the device is in use, open returns -EBUSY immediately in the
> latest version while it was blocked until released in the former
> version.
I suppose there was a "good reason" for changing the user level
interface in this way. Could you [or someone else] explain that and
if you would consider changing it back (to stop breaking old applications)?
Otherwise - is there some way (other than running lsmod and grep) to find
out if the interface is busy and which application is using it?
> > [2] When running latencytest (from
> > http://www.gardena.net/benno/linux/audio/) the sound is not consistent
> > (like it was on 2.4 with OSS) and occasionally I hear "rapid playback"
> > where the repeating audio pattern is much faster than it should be.
>
> It's hard to tell. The cause could be in the general interrupt
> handling, the difference of HZ, the driver's interrupt setting, or
> whatever. This must depend on the hardware, anyway.
Well, to a certain extent, I agree but let me repeat the symptoms
I am seeing [repeated below]
> > a. The time between write() calls to the audio interface varies from
> > roughly 1.16 msec to 2.0 msec. If you add code to dump out the
durations
> > you can see it is a sawtooth pattern, some periods it returns too
quickly
> > and some periods it returns too slowly.
What you describe can certainly explain this first behavior. For example,
if the ALSA code waits for the next clock tick (1 msec resolution)
to return from the write() call, the behavior I see can be explained. I do
not necessarily LIKE this behavior (it makes the analysis of latency and
explanations to other people more difficult) but I understand it and when
this happens - the sound is OK.
> > b. The time between write() calls is roughly 1.2 msec. I believe this
> > behavior occurs at the same time the audio pattern repeats too quickly.
This behavior on the other hand does not appear reasonable to me. The
latencytest application writes a series of audio fragments, each 1.45 msec
long.
It should never get an extended period (many seconds) where the loop doing
that
gets done at a 1.2 msec rate. What I hear from the speakers (the rapid
playback) does not sound right either. This looks like a bug to me that
needs to be corrected.
I can generally trigger it by running latencytest while reading (or
copying)
a large disk file with the kernels I have been building. Perhaps a long
latency
(> 1 audio fragment - 1.45 msec) is getting the ALSA code into a "hurry up"
mode
which it never leaves. That would explain the symptom but I certainly don't
know the code good enough to tell if that is feasible (or if something else
is causing the symptom).
--Mark H Johnson
<mailto:[email protected]>
On Mer, 2005-01-05 at 14:21, [email protected] wrote:
> > The default blocking behavior of OSS devices was changed recently.
> > When the device is in use, open returns -EBUSY immediately in the
> > latest version while it was blocked until released in the former
> > version.
> I suppose there was a "good reason" for changing the user level
> interface in this way. Could you [or someone else] explain that and
> if you would consider changing it back (to stop breaking old applications)?
> Otherwise - is there some way (other than running lsmod and grep) to find
> out if the interface is busy and which application is using it?
OSS itself changed behaviour over time (2.2 to 2.4) ALSA has merely
caught up with the newer OSS behaviour and the new behaviour is correct.
If you want to find out if the interface is busy open it. If you want to
do it portably open it with O_NDELAY.
At Wed, 5 Jan 2005 08:21:20 -0600,
[email protected] wrote:
>
> > At Tue, 4 Jan 2005 13:25:40 -0600,
> > [email protected] wrote:
> > > [snip - how to get to the problem]
> > > At this point, I get the window asking if I heard the sound (I did
> not). If
> > > I repeat the test after waiting a short period, it eventually succeeds.
> >
> > The default blocking behavior of OSS devices was changed recently.
> > When the device is in use, open returns -EBUSY immediately in the
> > latest version while it was blocked until released in the former
> > version.
> I suppose there was a "good reason" for changing the user level
> interface in this way. Could you [or someone else] explain that and
> if you would consider changing it back (to stop breaking old applications)?
It was discussed on alsa-devel in November. Unfortunately, I can't
find ML archive any longer...
The blocking behavior of OSS is a feature which is nowehre defined.
Some OSS drivers open in the blocking mode and some don't.
So, apps shouldn't depend on this feature.
We had implemented OSS emulation in the blocking manner since we
intepreted the POSIX definition in that way. But Linus pointed out
that it's a misreading.
BTW, you can enable the blocking mode again via module/boot option.
See OSS-Emulation.txt.
> > > [2] When running latencytest (from
> > > http://www.gardena.net/benno/linux/audio/) the sound is not consistent
> > > (like it was on 2.4 with OSS) and occasionally I hear "rapid playback"
> > > where the repeating audio pattern is much faster than it should be.
> >
> > It's hard to tell. The cause could be in the general interrupt
> > handling, the difference of HZ, the driver's interrupt setting, or
> > whatever. This must depend on the hardware, anyway.
> Well, to a certain extent, I agree but let me repeat the symptoms
> I am seeing [repeated below]
Please provide the hardware details (I don't see your original post to
lkml). Otherwise it'll be a vapor discusson...
Takashi
On Wed, 2005-01-05 at 14:56 +0000, Alan Cox wrote:
> On Mer, 2005-01-05 at 14:21, [email protected] wrote:
> > > The default blocking behavior of OSS devices was changed recently.
> > > When the device is in use, open returns -EBUSY immediately in the
> > > latest version while it was blocked until released in the former
> > > version.
> > I suppose there was a "good reason" for changing the user level
> > interface in this way. Could you [or someone else] explain that and
> > if you would consider changing it back (to stop breaking old applications)?
> > Otherwise - is there some way (other than running lsmod and grep) to find
> > out if the interface is busy and which application is using it?
>
> OSS itself changed behaviour over time (2.2 to 2.4) ALSA has merely
> caught up with the newer OSS behaviour and the new behaviour is correct.
>
> If you want to find out if the interface is busy open it. If you want to
> do it portably open it with O_NDELAY.
>
And if you want to find out who is using it then try fuser /dev/dsp,
fuser /dev/snd/*, or lsof.
Lee
On Wed, 2005-01-05 at 17:49 +0100, Takashi Iwai wrote:
> At Wed, 5 Jan 2005 08:21:20 -0600,
> [email protected] wrote:
> >
> > > At Tue, 4 Jan 2005 13:25:40 -0600,
> > > [email protected] wrote:
> > > > [snip - how to get to the problem]
> > > > At this point, I get the window asking if I heard the sound (I did
> > not). If
> > > > I repeat the test after waiting a short period, it eventually succeeds.
> > >
> > > The default blocking behavior of OSS devices was changed recently.
> > > When the device is in use, open returns -EBUSY immediately in the
> > > latest version while it was blocked until released in the former
> > > version.
> > I suppose there was a "good reason" for changing the user level
> > interface in this way. Could you [or someone else] explain that and
> > if you would consider changing it back (to stop breaking old applications)?
>
> It was discussed on alsa-devel in November. Unfortunately, I can't
> find ML archive any longer...
>
Heh, if you want the excruciating details, here are some pointers. It's
a long thread, and unfortunately the threading is a little broken.
Here's a link to the technical part:
http://sourceforge.net/mailarchive/message.php?msg_id=10008900
And here's the rant that started it:
http://sourceforge.net/mailarchive/message.php?msg_id=10014826
Lee