Strange behavior when writing( SNDCTL_MIX_WRITE ) vey fast.

[o***@lilltiger.se]

When calling:

ioctl(device_, SNDCTL_MIX_WRITE, &vr);

to fast the device will act up but not reporting any errors, atleast
when changing the volume.
The result is that the values written becomes random (often 0, but seen
other values as well).

This is realy bad for GUI apps using slider to change the values as
they will spam writes extreamly fast and this will mess upp the values.


ossinfo:

Version info: OSS 4.2 (b 2002/200911201634) (0x00040100) OSS_HG
Hg revision: changeset: 874:3c6677155802, tag: tip, date: Sat Nov 07
10:17:46 2009 +0200, summary: Changed build ID to v4.2-build2002
Platform: Linux/x86_64 2.6.35-gentoo-r1 #1 SMP Thu Aug 26 04:04:44 CEST
2010 (orion)

Number of audio devices: 12
Number of audio engines: 17
Number of MIDI devices: 0
Number of mixer devices: 2


Device objects
0: osscore0 OSS core services
1: oss_hdaudio0 Intel HD Audio interrupts=1132412466 (1132412466)
HD Audio controller Intel HD Audio
Vendor ID 0x8086293e
Subvendor ID 0x10438277
Codec 0: AD1988B (0x11d4198b/0x1043829c)
2: oss_usb0 USB audio core services
3: usb046d08ad-0 USB sound device
4: usb046d08ad-1 USB sound device

MIDI devices (/dev/midi*)

Mixer devices
0: High Definition Audio AD1988B (Mixer 0 of device object 1)
1: USB sound device (Mixer 0 of device object 3)

Audio devices
HD Audio play front /dev/oss/oss_hdaudio0/pcm0 (device
index 0)
HD Audio play center/LFE /dev/oss/oss_hdaudio0/pcm1 (device
index 1)
HD Audio play rear /dev/oss/oss_hdaudio0/pcm2 (device
index 2)
HD Audio play side /dev/oss/oss_hdaudio0/pcm3 (device
index 3)
HD Audio play headphone /dev/oss/oss_hdaudio0/pcm4 (device
index 4)
HD Audio play spdifout-mix /dev/oss/oss_hdaudio0/spdout0
(device index 5)
HD Audio rec rec1-src /dev/oss/oss_hdaudio0/pcmin0 (device
index 6)
HD Audio rec rec2-src /dev/oss/oss_hdaudio0/pcmin1 (device
index 7)
HD Audio rec rec3-src /dev/oss/oss_hdaudio0/pcmin2 (device
index 8)
HD Audio rec spdif-in /dev/oss/oss_hdaudio0/spdin0 (device
index 9)
HD Audio play front (vmix) loopback record /dev/oss/oss_hdaudio0/loop0
(device index 10)
USB sound device rec /dev/oss/usb046d08ad-1/pcmin0
(device index 11)

Nodes
/dev/dsp -> /dev/oss/oss_hdaudio0/pcm0
/dev/dsp_in -> /dev/oss/oss_hdaudio0/pcm0
/dev/dsp_out -> /dev/oss/oss_hdaudio0/pcm0
/dev/dsp_ac3 -> /dev/oss/oss_hdaudio0/spdout0
/dev/dsp_mmap -> /dev/oss/oss_hdaudio0/pcm0
/dev/dsp_multich -> /dev/oss/oss_hdaudio0/pcm0

[Hannu Savolainen]

Hi,

I have never seen this. It's probably a hardware level bug in the
AD1988B codec.

Best regards,

Hannu
----
29.11.2010 6.54, ***@lilltiger.se wrote:
>
> When calling:
>
> ioctl(device_, SNDCTL_MIX_WRITE, &vr);
>
> to fast the device will act up but not reporting any errors, atleast
> when changing the volume.
> The result is that the values written becomes random (often 0, but seen
> other values as well).
>
> This is realy bad for GUI apps using slider to change the values as
> they will spam writes extreamly fast and this will mess upp the values.
>
>
> ossinfo:
>
> Version info: OSS 4.2 (b 2002/200911201634) (0x00040100) OSS_HG
> Hg revision: changeset: 874:3c6677155802, tag: tip, date: Sat Nov 07
> 10:17:46 2009 +0200, summary: Changed build ID to v4.2-build2002
> Platform: Linux/x86_64 2.6.35-gentoo-r1 #1 SMP Thu Aug 26 04:04:44 CEST
> 2010 (orion)
>
> Number of audio devices: 12
> Number of audio engines: 17
> Number of MIDI devices: 0
> Number of mixer devices: 2
>
>
> Device objects
> 0: osscore0 OSS core services
> 1: oss_hdaudio0 Intel HD Audio interrupts=1132412466 (1132412466)
> HD Audio controller Intel HD Audio
> Vendor ID 0x8086293e
> Subvendor ID 0x10438277
> Codec 0: AD1988B (0x11d4198b/0x1043829c)
> 2: oss_usb0 USB audio core services
> 3: usb046d08ad-0 USB sound device
> 4: usb046d08ad-1 USB sound device
>
> MIDI devices (/dev/midi*)
>
> Mixer devices
> 0: High Definition Audio AD1988B (Mixer 0 of device object 1)
> 1: USB sound device (Mixer 0 of device object 3)
>
> Audio devices
> HD Audio play front /dev/oss/oss_hdaudio0/pcm0 (device
> index 0)
> HD Audio play center/LFE /dev/oss/oss_hdaudio0/pcm1 (device
> index 1)
> HD Audio play rear /dev/oss/oss_hdaudio0/pcm2 (device
> index 2)
> HD Audio play side /dev/oss/oss_hdaudio0/pcm3 (device
> index 3)
> HD Audio play headphone /dev/oss/oss_hdaudio0/pcm4 (device
> index 4)
> HD Audio play spdifout-mix /dev/oss/oss_hdaudio0/spdout0
> (device index 5)
> HD Audio rec rec1-src /dev/oss/oss_hdaudio0/pcmin0 (device
> index 6)
> HD Audio rec rec2-src /dev/oss/oss_hdaudio0/pcmin1 (device
> index 7)
> HD Audio rec rec3-src /dev/oss/oss_hdaudio0/pcmin2 (device
> index 8)
> HD Audio rec spdif-in /dev/oss/oss_hdaudio0/spdin0 (device
> index 9)
> HD Audio play front (vmix) loopback record /dev/oss/oss_hdaudio0/loop0
> (device index 10)
> USB sound device rec /dev/oss/usb046d08ad-1/pcmin0
> (device index 11)
>
> Nodes
> /dev/dsp -> /dev/oss/oss_hdaudio0/pcm0
> /dev/dsp_in -> /dev/oss/oss_hdaudio0/pcm0
> /dev/dsp_out -> /dev/oss/oss_hdaudio0/pcm0
> /dev/dsp_ac3 -> /dev/oss/oss_hdaudio0/spdout0
> /dev/dsp_mmap -> /dev/oss/oss_hdaudio0/pcm0
> /dev/dsp_multich -> /dev/oss/oss_hdaudio0/pcm0
>
> _______________________________________________
> oss-devel mailing list
> oss-***@mailman.opensound.com
> http://mailman.opensound.com/mailman/listinfo/oss-devel

[o***@lilltiger.se]

It should be realy easy to test on any other card, jusr run a loop that
reads the value of an volume mixer and then write this value back to it
right away.

like:
oss_mixer_value vr;
vr.dev=extinfo.dev;
vr.ctrl=extinfo.ctrl;
vr.timestamp=extinfo.timestamp;
vr.value=value;

while(true)
{
if( ioctl(device_, SNDCTL_MIX_READ, &vr) == -1 )
{
}
if( ioctl(device_, SNDCTL_MIX_WRITE, &vr) == -1 )
{
}
}

If the values dosent go ballistic then it's for sure and hardware
issue.


But either way, should the backend realy allow for this fast writes of
the values as it makes no sense, eats extra io/cpu for no gain at all.
In my opinion it should be better if the write function checks if it's
the same controler writing, if so keep an storage of that value and
allow that value to change for 100ms then write it to the hardware.
If another controler writes, then write the stored value, and the value
from the new controler. (this is what I did in my GUI to make it work as
it should).

On Mon, 29 Nov 2010 16:10:26 +0200, Hannu Savolainen
<***@opensound.com> wrote:
> Hi,
>
> I have never seen this. It's probably a hardware level bug in the
> AD1988B codec.
>
> Best regards,
>
> Hannu
> ----
> 29.11.2010 6.54, ***@lilltiger.se wrote:
>>
>> When calling:
>>
>> ioctl(device_, SNDCTL_MIX_WRITE, &vr);
>>
>> to fast the device will act up but not reporting any errors,
>> atleast
>> when changing the volume.
>> The result is that the values written becomes random (often 0, but
>> seen
>> other values as well).
>>
>> This is realy bad for GUI apps using slider to change the values as
>> they will spam writes extreamly fast and this will mess upp the
>> values.
>>
>>
>> ossinfo:
>>
>> Version info: OSS 4.2 (b 2002/200911201634) (0x00040100) OSS_HG
>> Hg revision: changeset: 874:3c6677155802, tag: tip, date: Sat Nov
>> 07
>> 10:17:46 2009 +0200, summary: Changed build ID to v4.2-build2002
>> Platform: Linux/x86_64 2.6.35-gentoo-r1 #1 SMP Thu Aug 26 04:04:44
>> CEST
>> 2010 (orion)
>>
>> Number of audio devices: 12
>> Number of audio engines: 17
>> Number of MIDI devices: 0
>> Number of mixer devices: 2
>>
>>
>> Device objects
>> 0: osscore0 OSS core services
>> 1: oss_hdaudio0 Intel HD Audio interrupts=1132412466 (1132412466)
>> HD Audio controller Intel HD Audio
>> Vendor ID 0x8086293e
>> Subvendor ID 0x10438277
>> Codec 0: AD1988B (0x11d4198b/0x1043829c)
>> 2: oss_usb0 USB audio core services
>> 3: usb046d08ad-0 USB sound device
>> 4: usb046d08ad-1 USB sound device
>>
>> MIDI devices (/dev/midi*)
>>
>> Mixer devices
>> 0: High Definition Audio AD1988B (Mixer 0 of device object 1)
>> 1: USB sound device (Mixer 0 of device object 3)
>>
>> Audio devices
>> HD Audio play front /dev/oss/oss_hdaudio0/pcm0
>> (device
>> index 0)
>> HD Audio play center/LFE /dev/oss/oss_hdaudio0/pcm1
>> (device
>> index 1)
>> HD Audio play rear /dev/oss/oss_hdaudio0/pcm2
>> (device
>> index 2)
>> HD Audio play side /dev/oss/oss_hdaudio0/pcm3
>> (device
>> index 3)
>> HD Audio play headphone /dev/oss/oss_hdaudio0/pcm4
>> (device
>> index 4)
>> HD Audio play spdifout-mix /dev/oss/oss_hdaudio0/spdout0
>> (device index 5)
>> HD Audio rec rec1-src /dev/oss/oss_hdaudio0/pcmin0
>> (device
>> index 6)
>> HD Audio rec rec2-src /dev/oss/oss_hdaudio0/pcmin1
>> (device
>> index 7)
>> HD Audio rec rec3-src /dev/oss/oss_hdaudio0/pcmin2
>> (device
>> index 8)
>> HD Audio rec spdif-in /dev/oss/oss_hdaudio0/spdin0
>> (device
>> index 9)
>> HD Audio play front (vmix) loopback record
>> /dev/oss/oss_hdaudio0/loop0
>> (device index 10)
>> USB sound device rec /dev/oss/usb046d08ad-1/pcmin0
>> (device index 11)
>>
>> Nodes
>> /dev/dsp -> /dev/oss/oss_hdaudio0/pcm0
>> /dev/dsp_in -> /dev/oss/oss_hdaudio0/pcm0
>> /dev/dsp_out -> /dev/oss/oss_hdaudio0/pcm0
>> /dev/dsp_ac3 -> /dev/oss/oss_hdaudio0/spdout0
>> /dev/dsp_mmap -> /dev/oss/oss_hdaudio0/pcm0
>> /dev/dsp_multich -> /dev/oss/oss_hdaudio0/pcm0
>>
>> _______________________________________________
>> oss-devel mailing list
>> oss-***@mailman.opensound.com
>> http://mailman.opensound.com/mailman/listinfo/oss-devel
>
> _______________________________________________
> oss-devel mailing list
> oss-***@mailman.opensound.com
> http://mailman.opensound.com/mailman/listinfo/oss-devel

[Hannu Savolainen]

Hi,

The logic for preventing too frequent writes belongs to the application.
It is not responsibility of the driver to prevent applications from
doing stupid things. Sometimes it's necessay and easy but not in this case.

Best regards,

Hannu
---
29.11.2010 16.37, ***@lilltiger.se wrote:
> It should be realy easy to test on any other card, jusr run a loop that
> reads the value of an volume mixer and then write this value back to it
> right away.
>
> like:
> oss_mixer_value vr;
> vr.dev=extinfo.dev;
> vr.ctrl=extinfo.ctrl;
> vr.timestamp=extinfo.timestamp;
> vr.value=value;
>
> while(true)
> {
> if( ioctl(device_, SNDCTL_MIX_READ, &vr) == -1 )
> {
> }
> if( ioctl(device_, SNDCTL_MIX_WRITE, &vr) == -1 )
> {
> }
> }
>
> If the values dosent go ballistic then it's for sure and hardware
> issue.
>
>
> But either way, should the backend realy allow for this fast writes of
> the values as it makes no sense, eats extra io/cpu for no gain at all.
> In my opinion it should be better if the write function checks if it's
> the same controler writing, if so keep an storage of that value and
> allow that value to change for 100ms then write it to the hardware.
> If another controler writes, then write the stored value, and the value
> from the new controler. (this is what I did in my GUI to make it work as
> it should).
>
> On Mon, 29 Nov 2010 16:10:26 +0200, Hannu Savolainen
> <***@opensound.com> wrote:
>> Hi,
>>
>> I have never seen this. It's probably a hardware level bug in the
>> AD1988B codec.
>>
>> Best regards,
>>
>> Hannu
>> ----
>> 29.11.2010 6.54, ***@lilltiger.se wrote:
>>>
>>> When calling:
>>>
>>> ioctl(device_, SNDCTL_MIX_WRITE, &vr);
>>>
>>> to fast the device will act up but not reporting any errors,
>>> atleast
>>> when changing the volume.
>>> The result is that the values written becomes random (often 0, but
>>> seen
>>> other values as well).
>>>
>>> This is realy bad for GUI apps using slider to change the values as
>>> they will spam writes extreamly fast and this will mess upp the
>>> values.
>>>
>>>
>>> ossinfo:
>>>
>>> Version info: OSS 4.2 (b 2002/200911201634) (0x00040100) OSS_HG
>>> Hg revision: changeset: 874:3c6677155802, tag: tip, date: Sat Nov
>>> 07
>>> 10:17:46 2009 +0200, summary: Changed build ID to v4.2-build2002
>>> Platform: Linux/x86_64 2.6.35-gentoo-r1 #1 SMP Thu Aug 26 04:04:44
>>> CEST
>>> 2010 (orion)
>>>
>>> Number of audio devices: 12
>>> Number of audio engines: 17
>>> Number of MIDI devices: 0
>>> Number of mixer devices: 2
>>>
>>>
>>> Device objects
>>> 0: osscore0 OSS core services
>>> 1: oss_hdaudio0 Intel HD Audio interrupts=1132412466 (1132412466)
>>> HD Audio controller Intel HD Audio
>>> Vendor ID 0x8086293e
>>> Subvendor ID 0x10438277
>>> Codec 0: AD1988B (0x11d4198b/0x1043829c)
>>> 2: oss_usb0 USB audio core services
>>> 3: usb046d08ad-0 USB sound device
>>> 4: usb046d08ad-1 USB sound device
>>>
>>> MIDI devices (/dev/midi*)
>>>
>>> Mixer devices
>>> 0: High Definition Audio AD1988B (Mixer 0 of device object 1)
>>> 1: USB sound device (Mixer 0 of device object 3)
>>>
>>> Audio devices
>>> HD Audio play front /dev/oss/oss_hdaudio0/pcm0
>>> (device
>>> index 0)
>>> HD Audio play center/LFE /dev/oss/oss_hdaudio0/pcm1
>>> (device
>>> index 1)
>>> HD Audio play rear /dev/oss/oss_hdaudio0/pcm2
>>> (device
>>> index 2)
>>> HD Audio play side /dev/oss/oss_hdaudio0/pcm3
>>> (device
>>> index 3)
>>> HD Audio play headphone /dev/oss/oss_hdaudio0/pcm4
>>> (device
>>> index 4)
>>> HD Audio play spdifout-mix /dev/oss/oss_hdaudio0/spdout0
>>> (device index 5)
>>> HD Audio rec rec1-src /dev/oss/oss_hdaudio0/pcmin0
>>> (device
>>> index 6)
>>> HD Audio rec rec2-src /dev/oss/oss_hdaudio0/pcmin1
>>> (device
>>> index 7)
>>> HD Audio rec rec3-src /dev/oss/oss_hdaudio0/pcmin2
>>> (device
>>> index 8)
>>> HD Audio rec spdif-in /dev/oss/oss_hdaudio0/spdin0
>>> (device
>>> index 9)
>>> HD Audio play front (vmix) loopback record
>>> /dev/oss/oss_hdaudio0/loop0
>>> (device index 10)
>>> USB sound device rec /dev/oss/usb046d08ad-1/pcmin0
>>> (device index 11)
>>>
>>> Nodes
>>> /dev/dsp -> /dev/oss/oss_hdaudio0/pcm0
>>> /dev/dsp_in -> /dev/oss/oss_hdaudio0/pcm0
>>> /dev/dsp_out -> /dev/oss/oss_hdaudio0/pcm0
>>> /dev/dsp_ac3 -> /dev/oss/oss_hdaudio0/spdout0
>>> /dev/dsp_mmap -> /dev/oss/oss_hdaudio0/pcm0
>>> /dev/dsp_multich -> /dev/oss/oss_hdaudio0/pcm0
>>>
>>> _______________________________________________
>>> oss-devel mailing list
>>> oss-***@mailman.opensound.com
>>> http://mailman.opensound.com/mailman/listinfo/oss-devel
>>
>> _______________________________________________
>> oss-devel mailing list
>> oss-***@mailman.opensound.com
>> http://mailman.opensound.com/mailman/listinfo/oss-devel
>
> _______________________________________________
> oss-devel mailing list
> oss-***@mailman.opensound.com
> http://mailman.opensound.com/mailman/listinfo/oss-devel

[o***@lilltiger.se]

Isent it the drivers job to make sure that applications do not have to
bother about potentional hardwahere issues,
The ossxmix has the same issues, althought because it happens less
because the updates is a little slower for somereason (havent checked
the code).
But either the driver should protect from to frequent writes, or the
docs should state very clearly that it does not do that and the user of
the library have to rule that in and not write to frequent.

And it's not realy a stupid thing of the application to do, I found
this issue by just making a slider to adjust the volume, and with a
responsive toolkit like Qt this slider will update it's values very fast
when moving the slider knobb.
And that causes alot of writes, and the doc's said nothing about this
being an issue at all so took quite a while before I figured out what
caused the strange behavior.

On Mon, 29 Nov 2010 16:46:45 +0200, Hannu Savolainen
<***@opensound.com> wrote:
> Hi,
>
> The logic for preventing too frequent writes belongs to the
> application.
> It is not responsibility of the driver to prevent applications from
> doing stupid things. Sometimes it's necessay and easy but not in this
> case.
>
> Best regards,
>
> Hannu
> ---
> 29.11.2010 16.37, ***@lilltiger.se wrote:
>> It should be realy easy to test on any other card, jusr run a loop
>> that
>> reads the value of an volume mixer and then write this value back
>> to it
>> right away.
>>
>> like:
>> oss_mixer_value vr;
>> vr.dev=extinfo.dev;
>> vr.ctrl=extinfo.ctrl;
>> vr.timestamp=extinfo.timestamp;
>> vr.value=value;
>>
>> while(true)
>> {
>> if( ioctl(device_, SNDCTL_MIX_READ, &vr) == -1 )
>> {
>> }
>> if( ioctl(device_, SNDCTL_MIX_WRITE, &vr) == -1 )
>> {
>> }
>> }
>>
>> If the values dosent go ballistic then it's for sure and hardware
>> issue.
>>
>>
>> But either way, should the backend realy allow for this fast writes
>> of
>> the values as it makes no sense, eats extra io/cpu for no gain at
>> all.
>> In my opinion it should be better if the write function checks if
>> it's
>> the same controler writing, if so keep an storage of that value and
>> allow that value to change for 100ms then write it to the hardware.
>> If another controler writes, then write the stored value, and the
>> value
>> from the new controler. (this is what I did in my GUI to make it
>> work as
>> it should).
>>
>> On Mon, 29 Nov 2010 16:10:26 +0200, Hannu Savolainen
>> <***@opensound.com> wrote:
>>> Hi,
>>>
>>> I have never seen this. It's probably a hardware level bug in the
>>> AD1988B codec.
>>>
>>> Best regards,
>>>
>>> Hannu
>>> ----
>>> 29.11.2010 6.54, ***@lilltiger.se wrote:
>>>>
>>>> When calling:
>>>>
>>>> ioctl(device_, SNDCTL_MIX_WRITE, &vr);
>>>>
>>>> to fast the device will act up but not reporting any errors,
>>>> atleast
>>>> when changing the volume.
>>>> The result is that the values written becomes random (often 0,
>>>> but
>>>> seen
>>>> other values as well).
>>>>
>>>> This is realy bad for GUI apps using slider to change the values
>>>> as
>>>> they will spam writes extreamly fast and this will mess upp the
>>>> values.
>>>>
>>>>
>>>> ossinfo:
>>>>
>>>> Version info: OSS 4.2 (b 2002/200911201634) (0x00040100) OSS_HG
>>>> Hg revision: changeset: 874:3c6677155802, tag: tip, date: Sat Nov
>>>> 07
>>>> 10:17:46 2009 +0200, summary: Changed build ID to v4.2-build2002
>>>> Platform: Linux/x86_64 2.6.35-gentoo-r1 #1 SMP Thu Aug 26
>>>> 04:04:44
>>>> CEST
>>>> 2010 (orion)
>>>>
>>>> Number of audio devices: 12
>>>> Number of audio engines: 17
>>>> Number of MIDI devices: 0
>>>> Number of mixer devices: 2
>>>>
>>>>
>>>> Device objects
>>>> 0: osscore0 OSS core services
>>>> 1: oss_hdaudio0 Intel HD Audio interrupts=1132412466
>>>> (1132412466)
>>>> HD Audio controller Intel HD Audio
>>>> Vendor ID 0x8086293e
>>>> Subvendor ID 0x10438277
>>>> Codec 0: AD1988B (0x11d4198b/0x1043829c)
>>>> 2: oss_usb0 USB audio core services
>>>> 3: usb046d08ad-0 USB sound device
>>>> 4: usb046d08ad-1 USB sound device
>>>>
>>>> MIDI devices (/dev/midi*)
>>>>
>>>> Mixer devices
>>>> 0: High Definition Audio AD1988B (Mixer 0 of device object 1)
>>>> 1: USB sound device (Mixer 0 of device object 3)
>>>>
>>>> Audio devices
>>>> HD Audio play front /dev/oss/oss_hdaudio0/pcm0
>>>> (device
>>>> index 0)
>>>> HD Audio play center/LFE /dev/oss/oss_hdaudio0/pcm1
>>>> (device
>>>> index 1)
>>>> HD Audio play rear /dev/oss/oss_hdaudio0/pcm2
>>>> (device
>>>> index 2)
>>>> HD Audio play side /dev/oss/oss_hdaudio0/pcm3
>>>> (device
>>>> index 3)
>>>> HD Audio play headphone /dev/oss/oss_hdaudio0/pcm4
>>>> (device
>>>> index 4)
>>>> HD Audio play spdifout-mix /dev/oss/oss_hdaudio0/spdout0
>>>> (device index 5)
>>>> HD Audio rec rec1-src /dev/oss/oss_hdaudio0/pcmin0
>>>> (device
>>>> index 6)
>>>> HD Audio rec rec2-src /dev/oss/oss_hdaudio0/pcmin1
>>>> (device
>>>> index 7)
>>>> HD Audio rec rec3-src /dev/oss/oss_hdaudio0/pcmin2
>>>> (device
>>>> index 8)
>>>> HD Audio rec spdif-in /dev/oss/oss_hdaudio0/spdin0
>>>> (device
>>>> index 9)
>>>> HD Audio play front (vmix) loopback record
>>>> /dev/oss/oss_hdaudio0/loop0
>>>> (device index 10)
>>>> USB sound device rec /dev/oss/usb046d08ad-1/pcmin0
>>>> (device index 11)
>>>>
>>>> Nodes
>>>> /dev/dsp -> /dev/oss/oss_hdaudio0/pcm0
>>>> /dev/dsp_in -> /dev/oss/oss_hdaudio0/pcm0
>>>> /dev/dsp_out -> /dev/oss/oss_hdaudio0/pcm0
>>>> /dev/dsp_ac3 -> /dev/oss/oss_hdaudio0/spdout0
>>>> /dev/dsp_mmap -> /dev/oss/oss_hdaudio0/pcm0
>>>> /dev/dsp_multich -> /dev/oss/oss_hdaudio0/pcm0
>>>>
>>>> _______________________________________________
>>>> oss-devel mailing list
>>>> oss-***@mailman.opensound.com
>>>> http://mailman.opensound.com/mailman/listinfo/oss-devel
>>>
>>> _______________________________________________
>>> oss-devel mailing list
>>> oss-***@mailman.opensound.com
>>> http://mailman.opensound.com/mailman/listinfo/oss-devel
>>
>> _______________________________________________
>> oss-devel mailing list
>> oss-***@mailman.opensound.com
>> http://mailman.opensound.com/mailman/listinfo/oss-devel
>
> _______________________________________________
> oss-devel mailing list
> oss-***@mailman.opensound.com
> http://mailman.opensound.com/mailman/listinfo/oss-devel

[François Revol]

_______________________________________________
oss-devel mailing list
oss-***@mailman.opensound.com
http://mailman.opensound.com/mailman/listinfo/oss-devel

[Hannu Savolainen]

Hi,

It doesn't make any sense anyway if an application makes repeated mixer
ioctl calls in row. In this way a full volume ramp will happen within a
millisecond. The application will have to do some delay between to calls
to make the ramp happen during an audible period.

The driver could have some additional oss_udelay() after the call but
this will just slow down all mixer calls. And the delay in kernel space
is atomic which will just waste CPU cycles. Doing that will not solve
any problems.

Hannu
---
29.11.2010 17.27, ***@lilltiger.se wrote:
> Isent it the drivers job to make sure that applications do not have to
> bother about potentional hardwahere issues,
> The ossxmix has the same issues, althought because it happens less
> because the updates is a little slower for somereason (havent checked
> the code).
> But either the driver should protect from to frequent writes, or the
> docs should state very clearly that it does not do that and the user of
> the library have to rule that in and not write to frequent.
>
> And it's not realy a stupid thing of the application to do, I found
> this issue by just making a slider to adjust the volume, and with a
> responsive toolkit like Qt this slider will update it's values very fast
> when moving the slider knobb.
> And that causes alot of writes, and the doc's said nothing about this
> being an issue at all so took quite a while before I figured out what
> caused the strange behavior.
>
> On Mon, 29 Nov 2010 16:46:45 +0200, Hannu Savolainen
> <***@opensound.com> wrote:
>> Hi,
>>
>> The logic for preventing too frequent writes belongs to the
>> application.
>> It is not responsibility of the driver to prevent applications from
>> doing stupid things. Sometimes it's necessay and easy but not in this
>> case.
>>
>> Best regards,
>>
>> Hannu
>> ---
>> 29.11.2010 16.37, ***@lilltiger.se wrote:
>>> It should be realy easy to test on any other card, jusr run a loop
>>> that
>>> reads the value of an volume mixer and then write this value back
>>> to it
>>> right away.
>>>
>>> like:
>>> oss_mixer_value vr;
>>> vr.dev=extinfo.dev;
>>> vr.ctrl=extinfo.ctrl;
>>> vr.timestamp=extinfo.timestamp;
>>> vr.value=value;
>>>
>>> while(true)
>>> {
>>> if( ioctl(device_, SNDCTL_MIX_READ, &vr) == -1 )
>>> {
>>> }
>>> if( ioctl(device_, SNDCTL_MIX_WRITE, &vr) == -1 )
>>> {
>>> }
>>> }
>>>
>>> If the values dosent go ballistic then it's for sure and hardware
>>> issue.
>>>
>>>
>>> But either way, should the backend realy allow for this fast writes
>>> of
>>> the values as it makes no sense, eats extra io/cpu for no gain at
>>> all.
>>> In my opinion it should be better if the write function checks if
>>> it's
>>> the same controler writing, if so keep an storage of that value and
>>> allow that value to change for 100ms then write it to the hardware.
>>> If another controler writes, then write the stored value, and the
>>> value
>>> from the new controler. (this is what I did in my GUI to make it
>>> work as
>>> it should).
>>>
>>> On Mon, 29 Nov 2010 16:10:26 +0200, Hannu Savolainen
>>> <***@opensound.com> wrote:
>>>> Hi,
>>>>
>>>> I have never seen this. It's probably a hardware level bug in the
>>>> AD1988B codec.
>>>>
>>>> Best regards,
>>>>
>>>> Hannu
>>>> ----
>>>> 29.11.2010 6.54, ***@lilltiger.se wrote:
>>>>>
>>>>> When calling:
>>>>>
>>>>> ioctl(device_, SNDCTL_MIX_WRITE, &vr);
>>>>>
>>>>> to fast the device will act up but not reporting any errors,
>>>>> atleast
>>>>> when changing the volume.
>>>>> The result is that the values written becomes random (often 0,
>>>>> but
>>>>> seen
>>>>> other values as well).
>>>>>
>>>>> This is realy bad for GUI apps using slider to change the values
>>>>> as
>>>>> they will spam writes extreamly fast and this will mess upp the
>>>>> values.
>>>>>
>>>>>
>>>>> ossinfo:
>>>>>
>>>>> Version info: OSS 4.2 (b 2002/200911201634) (0x00040100) OSS_HG
>>>>> Hg revision: changeset: 874:3c6677155802, tag: tip, date: Sat Nov
>>>>> 07
>>>>> 10:17:46 2009 +0200, summary: Changed build ID to v4.2-build2002
>>>>> Platform: Linux/x86_64 2.6.35-gentoo-r1 #1 SMP Thu Aug 26
>>>>> 04:04:44
>>>>> CEST
>>>>> 2010 (orion)
>>>>>
>>>>> Number of audio devices: 12
>>>>> Number of audio engines: 17
>>>>> Number of MIDI devices: 0
>>>>> Number of mixer devices: 2
>>>>>
>>>>>
>>>>> Device objects
>>>>> 0: osscore0 OSS core services
>>>>> 1: oss_hdaudio0 Intel HD Audio interrupts=1132412466
>>>>> (1132412466)
>>>>> HD Audio controller Intel HD Audio
>>>>> Vendor ID 0x8086293e
>>>>> Subvendor ID 0x10438277
>>>>> Codec 0: AD1988B (0x11d4198b/0x1043829c)
>>>>> 2: oss_usb0 USB audio core services
>>>>> 3: usb046d08ad-0 USB sound device
>>>>> 4: usb046d08ad-1 USB sound device
>>>>>
>>>>> MIDI devices (/dev/midi*)
>>>>>
>>>>> Mixer devices
>>>>> 0: High Definition Audio AD1988B (Mixer 0 of device object 1)
>>>>> 1: USB sound device (Mixer 0 of device object 3)
>>>>>
>>>>> Audio devices
>>>>> HD Audio play front /dev/oss/oss_hdaudio0/pcm0
>>>>> (device
>>>>> index 0)
>>>>> HD Audio play center/LFE /dev/oss/oss_hdaudio0/pcm1
>>>>> (device
>>>>> index 1)
>>>>> HD Audio play rear /dev/oss/oss_hdaudio0/pcm2
>>>>> (device
>>>>> index 2)
>>>>> HD Audio play side /dev/oss/oss_hdaudio0/pcm3
>>>>> (device
>>>>> index 3)
>>>>> HD Audio play headphone /dev/oss/oss_hdaudio0/pcm4
>>>>> (device
>>>>> index 4)
>>>>> HD Audio play spdifout-mix /dev/oss/oss_hdaudio0/spdout0
>>>>> (device index 5)
>>>>> HD Audio rec rec1-src /dev/oss/oss_hdaudio0/pcmin0
>>>>> (device
>>>>> index 6)
>>>>> HD Audio rec rec2-src /dev/oss/oss_hdaudio0/pcmin1
>>>>> (device
>>>>> index 7)
>>>>> HD Audio rec rec3-src /dev/oss/oss_hdaudio0/pcmin2
>>>>> (device
>>>>> index 8)
>>>>> HD Audio rec spdif-in /dev/oss/oss_hdaudio0/spdin0
>>>>> (device
>>>>> index 9)
>>>>> HD Audio play front (vmix) loopback record
>>>>> /dev/oss/oss_hdaudio0/loop0
>>>>> (device index 10)
>>>>> USB sound device rec /dev/oss/usb046d08ad-1/pcmin0
>>>>> (device index 11)
>>>>>
>>>>> Nodes
>>>>> /dev/dsp -> /dev/oss/oss_hdaudio0/pcm0
>>>>> /dev/dsp_in -> /dev/oss/oss_hdaudio0/pcm0
>>>>> /dev/dsp_out -> /dev/oss/oss_hdaudio0/pcm0
>>>>> /dev/dsp_ac3 -> /dev/oss/oss_hdaudio0/spdout0
>>>>> /dev/dsp_mmap -> /dev/oss/oss_hdaudio0/pcm0
>>>>> /dev/dsp_multich -> /dev/oss/oss_hdaudio0/pcm0
>>>>>
>>>>> _______________________________________________
>>>>> oss-devel mailing list
>>>>> oss-***@mailman.opensound.com
>>>>> http://mailman.opensound.com/mailman/listinfo/oss-devel
>>>>
>>>> _______________________________________________
>>>> oss-devel mailing list
>>>> oss-***@mailman.opensound.com
>>>> http://mailman.opensound.com/mailman/listinfo/oss-devel
>>>
>>> _______________________________________________
>>> oss-devel mailing list
>>> oss-***@mailman.opensound.com
>>> http://mailman.opensound.com/mailman/listinfo/oss-devel
>>
>> _______________________________________________
>> oss-devel mailing list
>> oss-***@mailman.opensound.com
>> http://mailman.opensound.com/mailman/listinfo/oss-devel
>
> _______________________________________________
> oss-devel mailing list
> oss-***@mailman.opensound.com
> http://mailman.opensound.com/mailman/listinfo/oss-devel