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

[stan]

On Fri, 13 Jul 2007 15:33:28 +0200
Takashi Iwai <tiwai at suse.de> wrote:

> At Fri, 13 Jul 2007 06:23:26 -0700,
> stan wrote:
> > 
[snip]
> 
> 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.

Darn!  I was hoping you would just look at it and know the problem. :-)

How would I go about that?  Is there a document somewhere that
describes the process?  I've downloaded the lib, drivers, utils, and
tools for 1.0.14.final.  I'll compile all of them.
If I install to /usr/local/, will it work?  I'm concerned about
breaking the packaging system / the system.
Do I modprobe the new kernel module from my own
build? It's been a while since I messed with such things.  I usually 
install applications outside the package management system, not base 
components like alsa.  Hand holding would be nice but if you just point
me towards some documentation that would be enough, or even describe
the outline of the process and I can use search to find documentation.

[snip]
>  
> 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.)

Done and attached below.

I am working on the rest of your requests and will send it along
later.
> 
> > 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?

I am using default, if I understand what you are asking.  I will set it
to use plughw:0,0 and try.
> 
> 
> > 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.
> 
That seems to have done the trick for both issues.  You did answer it
off the top of your head.  :-)

Minimum channels (1)
Maximum channels (10000)
Minimum rate (4000)  Direction = 0
Maximum rate (4294967295)  Direction = -1
Rate (48000)  Direction = -1 Result = 0
Rate (96000)  Direction = -1 Result = 0
Rate (192000)  Direction = -1 Result = 0
Rate (384000)  Direction = -1 Result = 0
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 buffer_time (170666)  Direction = 1
Actual buffer_size (32768)
Actual buffer_size (32768)
Actual period_time (85333)  Direction = 1
Actual period_size (16384)  Direction = 0
Actual periods (2)  Direction = 0
Actual rate (192000)  Direction = 0
Actual channels (2)
Actual periods (2)  Direction = 0
Actual period_size (16384)  Direction = 0
Actual buffer_size (32768)

What would be the effect of using plughw:0,0 instead of default on an
average system?  Would a user have any control over which sound card
plays the sound?  Or, to rephrase, with default if a user changes the
default then the sound card playing changes, with plughw:0,0 the user
is locked into the first card, true?

Let me know if you still want me to test 14 final, though it seems
redundant now.

 Thanks for your help.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ice1724_rc1_to_rc3.diff
Type: text/x-patch
Size: 13185 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20070713/015f937f/attachment-0003.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ice1712_rc1_to_rc3_h.diff
Type: text/x-patch
Size: 389 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20070713/015f937f/attachment-0004.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pcm_rc1_to_rc3.diff
Type: text/x-patch
Size: 1051 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20070713/015f937f/attachment-0005.diff