At Fri, 13 Jul 2007 06:23:26 -0700, stan wrote:
Hi,
This is going to be fairly long because of the explanations needed, but there are three problems I've found on my Revolution 5.1 between Alsa 1.0.14.RC1 and 1.0.14.RC3.
Could you check whether the same problem still exists on 1.0.14 final? There are tons of changes since rc3, so debugging rc3 is just a waste of time.
- Support for high sample rates 96000 and 192000 was lost.
- Sound distortion at high sound frequencies was introduced.
- The maximum buffer size seems too small for high sample rates (not related to release candidate).
Overview On Fedora 6 the alsa version is 1.0.14.RC1. Using that version, my application can use the high frequencies and there is no distortion introduced at high frequencies. On Fedora 7 the alsa version is 1.0.14.RC3. I can't use the high frequencies on the Revolution 5.1 and there is distortion introduced into the sound at high frequencies. In investigating this I noticed that the maximum buffer sizes seem small.
Here is the output from my app on Fedora 6 at 192000. (1.0.14.RC1) This works great!
Minimum channels (1) Maximum channels (10000) Minimum rate (4000) Direction = 0 Maximum rate (4294967295) Direction = -1 Minimum period_time (10) Direction = 1 Maximum period_time (2048000) Direction = 0 Minimum period_size (0) Direction = 1 Maximum period_size (4294967295) Direction = -1 Minimum periods (0) Direction = 1 Maximum periods (4294967295) Direction = 0 Minimum buffer_time (1) Direction = 0 Maximum buffer_time (4294967295) Direction = 0 Minimum buffer_size (1) Maximum buffer_size (4294967294) Minimum tick_time (1000) Direction = 0 Maximum tick_time (1000) Direction = 0 Actual rate (192000) Direction = 0 Actual channels (2) Actual period_size (8) Direction = 0 Actual buffer_size (8192) <--- notice that this is reasonable
Here is the output from my app on Fedora 7 at 192000. (1.0.14.RC3) This aborts while setting the hardware parameters with invalid argument.
Minimum channels (1) Maximum channels (10000) Minimum rate (4000) Direction = 0 Maximum rate (4294967295) Direction = -1 Rate (48000) Direction = -1 Result = 0 <-- from test rate Rate (96000) Direction = -1 Result = 0 Rate (192000) Direction = -1 Result = 0 <-- maximum for card hw Rate (384000) Direction = -1 Result = 0 <-- accepts invalid 384000 Minimum period_time (21333) Direction = 1 <-- seems strange the same Maximum period_time (21334) Direction = -1 Minimum period_size (85) Direction = 1 Maximum period_size (91628833) Direction = -1 Minimum periods (0) Direction = 1 Maximum periods (17247242) Direction = -1 Minimum buffer_time (1) Direction = 0 Maximum buffer_time (4294967295) Direction = 0 Minimum buffer_size (170) Maximum buffer_size (1466015503) Minimum tick_time (0) Direction = 0 Maximum tick_time (4294967295) Direction = 0 Actual rate (192000) Direction = 0 Actual channels (2) Actual buffer_time (341333) Direction = 1 Actual buffer_size (65536) Actual buffer_size (65536) Actual period_time (21333) Direction = 1 Actual period_size (807872295) Direction = 1 <--- Note invalid period size Actual periods (21333) Direction = 1 cannot set parameters (Invalid argument) Could not open the sound device
The two are on the same hardware, just different OS versions. While investigating I switched from using size to time as the allocation mechanism without any effect (using the sample from pcm.c on alsa site).
I did a diff on the ice1724.c driver (attached below) and noticed that there was a lot of cleanup done by making the structs and arrays of structs const. Could that possibly cause this problem by not allowing calculated values to be set? Don't know. 44100 and 48000 work.
No, consts shouldn't matter. (BTW, please use diff -up option at the next time. That'll make it way easier to read a patch.)
I ran a frequency loudness test that is part of the app. It drops the frequency at 5 seconds intervals from 20 KHz to 5 Hz alternating. On Fedora 6 with 1.0.14.RC1 it works as expected. When above my hearing range I hear silence. When it gets to frequencies I can hear the sound is pure. On Fedora 7, this same app produces noise at frequencies I can't hear. This behavior is the same as the behavior I noticed with my emu10k1, ca0106 and CK8S sound cards on 1.0.14.RC1 as well as 1.0.14.RC3. I previously had ascribed this to bad/low quality sound chips; now I'm not so sure. In terms of sound quality the Rev 5.1 ranks well. See the link
http://compreviews.about.com/od/multimedia/tp/SoundCards.htm
Exact same hardware produces different sound. Can't explain it. Can you? Can you fix it?
Might be alsa-lib dmix issue now used as default PCM? Which PCM configuration are you using? Does the problem exist even if you use "hw" (or "plughw") PCM explicitly?
While looking at the ice1724.c code I noticed that the maximum buffer size is 2**18. This seems small for an application today. I'm producing sound at 192000 frames per second (admittedly overkill though I like very smooth sound) using stereo doubles (16 bytes per frame). The maximum buffer size is only a fraction of my per second byte rate.
Could you increase this?
Ditto.
thanks,
Takashi