[alsa-devel] Some functionality of ice1724 broken between 1.0.14.RC1 and 1.0.14.RC3

[Takashi Iwai]

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