Noise in ice1724 based soundcard

[igorzwx]

Many times it is very helpful to find evidences that support our statements, don't think?

Yes. This is what economists must do, if they are true economists, because the purpose of economic science is to justify economic policy. Feynman called such things "Cargo Cult Science" http://calteches.library.caltech.edu/51/2/CargoCult.pdf

igorzwx wrote:
I would rather suggest that you are a sociologist (or economist), because you are always trying to prove you "hypotheses" (instead of trying to disprove them, as physicists must do).

This is funny, I was never told that my job was always try to disprove my hypothesis. Yes, this is a very healthful practice(that must be done by all scientists), but it is not the only practice that we must have... Many times it is very helpful to find evidences that support our statements, don't think? Specially when your are saying them for the first time... You should practice this "disprove rule" in your statements too...

Returning to the topic, surely the "SRC_SUPPORT" has something to do with a resampler, but not necessarily with vmix. My card has a option envy24.src that when enabled turns on a software resampler that works even when vmix is disabled(or seems to be...).

You may try to disable all resamplers and play 32bit 96kHz with "ossplay -R".

[wwmm]

In fact, the envy24.src option was disabled when I did that tests. I forgot to mention that, my bad...

[igorzwx]

In fact, the envy24.src option was disabled when I did that tests. I forgot to mention that, my bad...

We may better ask Cesium to explain this.
EDIT: I do not see such messages with "ossplay -R". This is how I usually test HW resamplers, playing 16bit 44100Hz with "ossplay -R".

Have you tried to reproduce noise with 32bit 48kHz wave?

[wwmm]

No, the 6 channels file that I have been testing is 16 bits and 44100 Hz. I will try to change the format and rate and post the results here.

EDIT: With a 32bit and 48 kHz file I can also hear noises when doing the "seek test".

[wwmm]

EDIT: I do not see such messages with "ossplay -R". This is how I usually test HW resamplers, playing 16bit 44100Hz with "ossplay -R".

If I play a 32bit, 48 kHz wave file I also do not see warning:

Code: Select all

[wallace@wwmm Live in Paris and Toronto]$ ossplay -vvR test4.wav
FORM len = 448358468
Playing WAVE file test4.wav, 32 bits/6 channels/48000 Hz
Setup device S32_LE/6/48000
Time: 00:25.80 of 06:29.20 VU -----      ^C
[wallace@wwmm Live in Paris and Toronto]$

It makes senses as this is a native speed. The warning only appears when I play files with rates higher than 48 kHz. If I play a 44100 Hz file(with the option ratelock disabled), for example, the envy24.rate is automatically switched to 44100 Hz(also a native speed) and I can see no warnings.

[igorzwx]

You do not need to mystify "native speed".

Code: Select all

$ ossmix vmix0-src OFF
Value of mixer control vmix0-src set to OFF

$ ossmix vmix0-enable ON
Value of mixer control vmix0-enable set to ON

$ ossmix | grep vmix0
vmix0-enable ON|OFF (currently ON)
vmix0-rate <decimal value> (currently 48000) (Read-only)
vmix0-channels <Stereo|Multich> (currently Stereo)
vmix0-src <Fast|High|High+|Production|OFF> (currently OFF)
vmix0-outvol <monovol> (currently 25.0 dB)
vmix0-invol <monovol> (currently 25.0 dB)
vmix0.pcm7 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm8 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm9 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm10 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)

$ ossplay *.wav
Warning: Playback using 48000 Hz (file 44100 Hz)


This configuration causes warning: "Warning: Playback using 48000 Hz (file 44100 Hz)".
However, 44100 Hz is a "native sample rate" for my card (ICH6):

Code: Select all

$ ossinfo -v9
Version info: OSS 4.2 (b 2003/201012180115) (0x00040100) GPL
Platform: Linux/i686 2.6.36-ARCH #1 SMP PREEMPT Fri Dec 10 20:01:53 UTC 2010 (cargo-cult)

Number of audio devices:   7
Number of audio engines:   11
Number of MIDI devices:      0
Number of mixer devices:   1


Device objects
0: osscore0 OSS core services
1: oss_hdaudio0 Intel HD Audio interrupts=6949 (18664)
    HD Audio controller Intel HD Audio
    Vendor ID    0x80862668
    Subvendor ID 0x17c02017
     Codec  0: AD1986A (0x11d41986/0x17c02017)
     Codec  1: Motorola3055 (0x10573055)
2: oss_usb0 USB audio core services

MIDI devices (/dev/midi*)

Mixer devices
0: High Definition Audio AD1986A (Mixer 0 of device object 1)
    Device file /dev/oss/oss_hdaudio0/mix0, Legacy device /dev/mixer0
    Priority: 10
    Caps:
    Device handle: PCI201717c0-0000:00:1b.0-mx01
    Device priority: 10


Audio devices
HD Audio play front               /dev/oss/oss_hdaudio0/pcm0  (device index 0)
    Legacy device /dev/dsp0
    Caps: DUPLEX TRIGGER MMAP
    Modes: IN/OUT
      Out engine  1: 0/HD Audio play front
                     Available for use
      Engine      2: 7/HD Audio play front (vmix)
                     Available for use
      Engine      3: 8/HD Audio play front (vmix)
                     Available for use
      Engine      4: 9/HD Audio play front (vmix)
                     Available for use
      Engine      5: 10/HD Audio play front (vmix)
                     Available for use
    Input formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Output formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Device handle: PCI201717c0-0000:00:1b.0-au01
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 2 - 8
    Native sample rates (min - max): 8000 - 48000 (8000,11025,16000,22050,32000,44100,48000)
    HW Type: Not indicated.
    Minimum latency: Not indicated

HD Audio play rear                /dev/oss/oss_hdaudio0/pcm1  (device index 1)
    Legacy device /dev/dsp1
    Caps: TRIGGER MMAP
    Modes: OUTPUT
      Out engine  1: 1/HD Audio play rear
                     Available for use
    Input formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Output formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Device handle: PCI201717c0-0000:00:1b.0-au02
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 2 - 2
    Native sample rates (min - max): 8000 - 48000 (8000,11025,16000,22050,32000,44100,48000)
    HW Type: Not indicated.
    Minimum latency: Not indicated

HD Audio play center/LFE          /dev/oss/oss_hdaudio0/pcm2  (device index 2)
    Legacy device /dev/dsp2
    Caps: TRIGGER MMAP
    Modes: OUTPUT
      Out engine  1: 2/HD Audio play center/LFE
                     Available for use
    Input formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Output formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Device handle: PCI201717c0-0000:00:1b.0-au03
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 2 - 2
    Native sample rates (min - max): 8000 - 48000 (8000,11025,16000,22050,32000,44100,48000)
    HW Type: Not indicated.
    Minimum latency: Not indicated

HD Audio play spdif-out           /dev/oss/oss_hdaudio0/spdout0  (device index 3)
    Legacy device /dev/dsp3
    Caps: TRIGGER MMAP
    Modes: OUTPUT
      Out engine  1: 3/HD Audio play spdif-out
                     Available for use
    Input formats (0x00000410):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_AC3      - AC3 (Dolby Digital) encoded audio
    Output formats (0x00000410):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_AC3      - AC3 (Dolby Digital) encoded audio
    Device handle: PCI201717c0-0000:00:1b.0-au04
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 2 - 2
    Native sample rates (min - max): 44100 - 48000 (44100,48000)
    HW Type: Not indicated.
    Minimum latency: Not indicated

HD Audio play modem               /dev/oss/oss_hdaudio0/mdmout0  (device index 4)
    Legacy device /dev/dsp4
    Caps: TRIGGER MMAP
    Modes: OUTPUT
      Out engine  1: 4/HD Audio play modem
                     Available for use
    Input formats (0x00000010):
      AFMT_S16_LE   - 16 bit signed little endian
    Output formats (0x00000010):
      AFMT_S16_LE   - 16 bit signed little endian
    Device handle: PCI201717c0-0000:00:1b.0-au05
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 1 - 1
    Native sample rates (min - max): 8000 - 16000 (8000,9600,16000)
    HW Type: Not indicated.
    Minimum latency: Not indicated

HD Audio rec rec-srcmic-mix       /dev/oss/oss_hdaudio0/pcmin0  (device index 5)
    Legacy device /dev/dsp5
    Caps: DUPLEX TRIGGER MMAP
    Modes: IN/OUT
      In engine   1: 5/HD Audio rec rec-srcmic-mix
                     Available for use
      Engine      2: 7/HD Audio play front (vmix)
                     Available for use
      Engine      3: 8/HD Audio play front (vmix)
                     Available for use
      Engine      4: 9/HD Audio play front (vmix)
                     Available for use
      Engine      5: 10/HD Audio play front (vmix)
                     Available for use
    Input formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Output formats (0x00001010):
      AFMT_S16_LE   - 16 bit signed little endian
      AFMT_S32_LE   - 32 bit signed little endian
    Device handle: PCI201717c0-0000:00:1b.0-au06
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 2 - 2
    Native sample rates (min - max): 8000 - 48000 (8000,11025,16000,22050,32000,44100,48000)
    HW Type: Not indicated.
    Minimum latency: Not indicated

HD Audio rec modem                /dev/oss/oss_hdaudio0/mdmin0  (device index 6)
    Legacy device /dev/dsp6
    Caps: TRIGGER MMAP
    Modes: INPUT 
      In engine   1: 6/HD Audio rec modem
                     Available for use
    Input formats (0x00000010):
      AFMT_S16_LE   - 16 bit signed little endian
    Output formats (0x00000010):
      AFMT_S16_LE   - 16 bit signed little endian
    Device handle: PCI201717c0-0000:00:1b.0-au07
    Related mixer dev: 0
    Sample rate source: 0
    Preferred channel configuration: Not indicated
    Supported number of channels (min - max): 1 - 1
    Native sample rates (min - max): 8000 - 16000 (8000,9600,16000)
    HW Type: Not indicated.
    Minimum latency: Not indicated


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


When vmix is disabled by "ossplay -R", I do not see any warnings.
The same is for ICH4, old VIA card, and any other (which I tested).

[wwmm]

You do not need to mystify "native speed".

I wasn't trying to mystify anything. I've been reading so much the driver source code, where the term "speed" is often used with the meaning of sample rate, that I replaced one by the other...

Though our cards seems to be a little different with respect to sampling rate control, I could reproduce your results here. I will try to summarize the results of my possible configurations. In the following a 16 bit,44100 Hz and 6 channels file was used:

-Vmix disabled, ratelock disabled,envy.src disabled: the sampling rate was automatically adjusted to 44100 and no warning was printed

-Vmix disabled, ratelock enabled with the value 48000 Hz, envy.src disabled: the warning is displayed(it makes sense as the card was forced to operate at 48000 and the file rate is 44100)

-Vmix disabled, ratelock enabled with the value 48000 Hz, envy.src enabled: no warning because the file sampling rate was converted(by envy24.src) from 44100 to 48000

-Vmix enabled, vmix.src HIGH, ratelock disabled,envy.src disabled: no warnings displayed(the card was set to 48000 by vmix but as vmix.src converted the file sampling rate to 48000 there was no warning)

-Vmix enabled, vmix.src OFF, ratelock disabled,envy.src disabled: the warning is displayed(the card was forced by vmix to operate at 48000 but as the file is 44100 a warning was displayed)

-Vmix enabled, vmix.src OFF, ratelock disabled,envy.src enabled: the warning is displayed (with vmix enabled the option envy24.src seems to be always disabled, so from here on I will ignore it)

-Vmix enabled, vmix.src OFF, ratelock enabled with the value 44100: no warning is displayed (with this configuration the vmix rate was automatically adjusted from 48000 to 44100, that's why there is no warning)

-Vmix enabled, vmix.src OFF, ratelock enabled with values different of 44100: a warning is always displayed (though the vmix rate is always equal to the value set in envy24.rate, such values are different than the one of the played file)

Obs.:with ratelock disabled and vmix enabled the card rate is automatically set to 48000, no matter the rate of the played file

At least in my card, I think that the warnings with enabled vmix and disabled vmix.src are caused because vmix always set the card to 48000 Hz, no matter the played file sampling rate. Without its built-in resampler, the card will almost always be forced to operate in a rate that is different from the one of the file. If before playing the file I use vmixctl to change vmix rate to 44100 and disable vmix.src there is no warning in the output of ossplay.

That's my explanation to the production of warnings in my card, as yours is completely different you may be seeing them for other reasons.

[igorzwx]

Obs.:with ratelock disabled and vmix enabled the card rate is automatically set to 48000, no matter the rate of the played file

What is "the card rate"?
Do you mean "vmix0-rate"?

Code: Select all

$ ossmix | grep vmix0-rate
vmix0-rate <decimal value> (currently 48000) (Read-only)


My "vmix0-rate" does not changes automatically, but I can change it (as root, or with sudo).

[wwmm]

What is "the card rate"?

In this envy24 card I have 2 sampling rate configuration options. The vmix0-rate, that as you know is the virtual mixer sampling rate and can only be configured as root, and envy24.rate that sets the sampling rate of the sound card hardware and can be set in ossxmix as normal user. You can read more about it doing "man oss_envy24". When vmix is enabled, it automatically sets the envy24.rate(the hardware rate) to 48 kHz, no matter the file sampling rate.

[igorzwx]

What is "the card rate"?

In this envy24 card I have 2 sampling rate configuration options. The vmix0-rate, that as you know is the virtual mixer sampling rate and can only be configured as root, and envy24.rate that sets the sampling rate of the sound card hardware and can be set in ossxmix as normal user. You can read more about it doing "man oss_envy24". When vmix is enabled, it automatically sets the envy24.rate(the hardware rate) to 48 kHz, no matter the file sampling rate.

If it is true, your "ossinfo" is O.K. and your "native rates" too.
You may try to reproduce noise with another player, "deadbeef", for example, or "xmms".

[cesium]

I haven't read all the recent posts, but I think I can clarify the discussion (especially as I made so many patches to ossplay that I'm not sure just if any of the original code is left):

A. SRC_SUPPORT is a define which is disabled by default and is not compiled in default ossplay. If it's enabled, GRC3 (the algo used by vmix for SRC) is compiled into ossplay, and ossplay would be able to convert sample rates by itself. The idea was to allow userland testing of GRC3, and I wanted to understand the algorithm.

B. The "Warning: Playback using..." message is outputted when the card does not support the rate of the play which is played (and when ossplay doesn't have SRC compiled in, which is the default). Since vmix has its own SRC, it normally happens only where vmix is disabled. Btw, I don't think you need to rebuild OSS with --config-vmix=NO to disable it - there are at least two separate ways to prevent it from touching the envy24ht card (e.g. setting "vmix0-enable" to OFF in the mixer).

C. I'm not so familiar with the driver. It has some commonalities with the envy24, and that man page ("man oss_envy24" - your driver is oss_envy24ht), suggests that the rate can be locked via "ratelock" and then only "rate" control can set the card's rate (this can be useful if one has one of those cards with hw mixing, and decides to avoid vmix).
Since vmix "talks" to the card at a certain rate, and that's the only rate the card will see if vmix is enabled (barring some special workarounds like 'ossplay -R -s32000' which almost never happen in actual use), I guess this ratelock mechanism is mostly useless (same function as 'sudo vmixctl rate') when vmix is used.

[igorzwx]

I haven't read all the recent posts, but I think I can clarify the discussion (especially as I made so many patches to ossplay that I'm not sure just if any of the original code is left):

A. SRC_SUPPORT is a define which is disabled by default and is not compiled in default ossplay. If it's enabled, GRC3 (the algo used by vmix for SRC) is compiled into ossplay, and ossplay would be able to convert sample rates by itself. The idea was to allow userland testing of GRC3, and I wanted to understand the algorithm.

B. The "Warning: Playback using..." message is outputted when the card does not support the rate of the play which is played (and when ossplay doesn't have SRC compiled in, which is the default). Since vmix has its own SRC, it normally happens only where vmix is disabled.

Just the contrary. It normally happens only when vmix is enabled.
This can be easily reproduced with many ordinary cards (such as ICH4, ICH6, VIA VT8233/A/8235/8237, and the like)
viewtopic.php?f=3&t=4159&start=60#p16624

The problem is that our "experimental physics" is "missing something essential", because we cannot design a clear-cut empirical test to find out whether the noise is produced by the driver, or by players.

EDIT: The noise can also be produced by libpulse, or other buggy things. There are already bug reports related to libpulse and /dev/shm , see:
https://bbs.archlinux.org/viewtopic.php?id=110398
http://comments.gmane.org/gmane.linux.d ... audio/2160
http://www.mail-archive.com/pkg-pulseau ... 01655.html
What is more, it seems that libpulse tends to behave like a trojan, or rootkit, and, therefore, you may get warnings from "rkhunter", see:
http://forums.techguy.org/linux-unix/88 ... found.html
https://bugs.launchpad.net/ubuntu/+sour ... bug/559545

"libpulse" is not difficult to remove. The problem is that we have not a reliable player for OSS4, and, therefore, we can only create an esoteric mythology which explains the phenomenon.

Petrov's pcm_play does support seeking, resampling and conversion (stereo → surround), it can also disable vmix (similar to "ossplay -R"). However, pcm_play has not been published yet (you may get it from the author, perhaps; it is said to be free, but not "open source").

Taking into account that Sergey created his pcm_play during two days... It works well, nevertheless.

It might be nice to have resamplers enabled in ossplay, but the problem is that OSS4 resamplers are fundamentally buggy. Has anybody tried to downsample HD audio (e.g. 32bit 192kHz) with OSS4 resamplers?

In particular, "Fast" resampler is so bad, that is might be reasonable to disable it in OSS4
viewtopic.php?f=3&t=4035#p16005

EDIT: Generally speaking, the problem of resampling was solved in 19th century. But Linux is so advanced... (in this sense), not to mention PulseAudio...

I do not know exactly, but it looks like Sergey implemented those ancient mathematical formulae in his resampler (they seem to work well).

[wwmm]

I have just recompiled mplayer with --disable-pulse and I still can hear noises when doing a seek in the file.

In my system the directory /dev/shm is empty, is this a problem?

[igorzwx]

I have just recompiled mplayer with --disable-pulse and I still can hear noises when doing a seek in the file.

In my system the directory /dev/shm is empty, is this a problem?

I do not have libpulse installed.
/dev/shm is empty too (perhaps, it is reserved for trojans).

Code: Select all

$ fuser -vvvv /dev/shm
                     USER        PID ACCESS COMMAND
/dev/shm:            root     kernel mount /dev/shm


Have you tried to reproduce noise with another player (deadbeef, xmms, or else)?
Deadbeef has a special OSS4 plugin (open source).
There is also a very special OSS4 plugin for Deadbeef created by Sergey Petrov (you may try to get it from the author; it is said to be free, but not "open source").
xmms is maintained by OSS4 developers http://www.xmms.org/

[wwmm]

I tried to play a 6 channel file in xmms and deadbeaf but it was not possible. Xmms just did nothing and deadbeaf played only 2 of the 6 channels, despite its status bar was showing "6 channels". My only option to reproduce the noise was to play a stereo file with vmix enabled and set to Multich. Here are the results:

- Xmms behaved identically to mplayer, vlc, gstreamer(via phonon) and xine(via phonon). Noises were produced everytime I did a forward/backward seek in the file;

- With deadbeaf I could hear strange noises whenever I clicked the play/pause buttons but there was no noise during seeks.