On Tue, 2 Sep 2003, James Courtier-Dutton wrote:
> Jaroslav Kysela wrote:
> > On Tue, 2 Sep 2003, James Courtier-Dutton wrote:
> >
> >
> >>Jaroslav Kysela wrote:
> >>
> >>>On Mon, 1 Sep 2003, James Courtier-Dutton wrote:
> >>>
> >>>
> >>>
> >>>>I have found two problems with using the dmix alsa device name.
> >>>>1) snd_pcm_hw_params_can_pause (params) causes alsa-lib to assert!
> >>>>
> >>>>2) Sound is broken up.
> >>>>a) It can only function with 2 periods, why is that? Having 8 periods
> >>>>might be better, although "front" works fine with 2 periods, but "dmix"
> >>>>with 2 periods fails.
> >>
> >>See attachment dmix-fail.c
> >>compile with
> >>gcc -g -DDEBUG -lasound a.c
> >>
> >>Shows problem (1) and (2)
> >
> >
> > (1)
> >
> > The count of used periods is probably 2.73 for 64kB buffer, my setup is:
> >
> > buffer_size : 16384
> > period_size : 6000
> >
> > If you want another setup, you must write your own configuration to
> > ~/.asoundrc.
> >
> > (2)
> >
> > Problem with uninitialized pcm->info value is fixed in CVS.
> >
> >
> >>>>b) Of the 2 periods, it sounds like sound is only being played from one
> >>>>of the periods, with silence for the other period.
> >>>>
> >>
> >>I don't have a small compilable example for this yet. The problem
> >>application is the latest xine cvs. (xine.sf.net)
> >
> >
> > Note that it might be caused that your code is broken. Please, use the
> > correct transfer unit (period_size) and not the period count which might
> > be a real not integer value, thus buffer_size / period_size !=
> > integer(period_count).
> >
> > Jaroslav
> >
> > -----
> > Jaroslav Kysela <[EMAIL PROTECTED]>
> > Linux Kernel Sound Maintainer
> > ALSA Project, SuSE Labs
> >
> >
> The aim of my code is to try for a buffer that is about 1 second long or
> less, and has hopefully 8 periods.
> I had always assumed that the period_count had to be an integer.
> If it is in fact possible to to have the period_count a non-interger on
> all sound cards, then I will change my code.
Most cards does not have such constraint, so yes, this fact should be
handled. The dmix plugin comes with these "strange" defaults mainly for
the application developers to debug their "broken" code which does not
conform fully the ALSA semantics.
> The problem with trying the period_size approach was: -
> set_buffer_time_near(1 second)
> size = get_buffer_size() (e.g. this gets set to 16384)
> set_period_size_near(size/8, dir=0) (e.g. try to set period_size to
> 2048) <- Failed on some cards/devices that did not like 8 periods.
>
> I thought that set_period_size_near with a dir=0, should have resulted
> in a setting of 6000 for "dmix", but it in-fact failed, and I did not
> want to go round a loop trying different period sizes until one worked.
>
> Does this point to a bug in the set_period_size_near function then?
Maybe. I used your test code and set_period_size_near() works as expected
with the trident driver. Which cards are failing?
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
