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. > 1. Support for high sample rates 96000 and 192000 was lost. > 2. Sound distortion at high sound frequencies was introduced. > 3. 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. > > 1. > > 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.) > 2. > > 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? > 3. > > 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
