Re: [Alsa-user] strange period size behaviour

2006-09-21 Thread Clemens Ladisch
Sergei Steshenko wrote: > Tomas Carnecky <[EMAIL PROTECTED]> wrote: > > Clemens Ladisch wrote: > > > Your application must be able to handle any period size. > > > > > > Why does the period size matter at all? > > > > My app can handle that now, but the way how I had to do it defeats the > > 'ze

Re: [Alsa-user] strange period size behaviour

2006-09-21 Thread Lee Revell
On Thu, 2006-09-21 at 08:55 +0200, Tomas Carnecky wrote: > Lee Revell wrote: > > You are mixing up period_time (which is in microseconds) with > > period_size (which is in frames). period_time defaults to 125000. > > > > Why do you want to use an .asoundrc at all? > > > > I want to set period s

Re: [Alsa-user] strange period size behaviour

2006-09-21 Thread Alfons Adriaensen
On Thu, Sep 21, 2006 at 02:09:30PM +0200, Tomas Carnecky wrote: > If we're at it, can I snd_pcm_mmap_begin()/commit() more than 4096 > bytes? It seems as at it's possible since wine's alsa driver does that > on the whole buffer, which can be more than 4096 bytes. Certainly it can. My soundcard

Re: [Alsa-user] strange period size behaviour

2006-09-21 Thread Sergei Steshenko
On Thu, 21 Sep 2006 14:09:30 +0200 Tomas Carnecky <[EMAIL PROTECTED]> wrote: > Sergei Steshenko wrote: > > I might be wrong, but it seems that 4096 bytes limit comes from these > > facts: > > > > 1) on Linux page size is 4096 bytes; > > 2) if one allocate more than 4096 bytes, the system cannot g

Re: [Alsa-user] strange period size behaviour

2006-09-21 Thread Tomas Carnecky
Sergei Steshenko wrote: > I might be wrong, but it seems that 4096 bytes limit comes from these > facts: > > 1) on Linux page size is 4096 bytes; > 2) if one allocate more than 4096 bytes, the system cannot guarantee the > pages are contiguous; > 3) ALSA uses DMA whenever the card supports it; > 4

Re: [Alsa-user] strange period size behaviour

2006-09-21 Thread Sergei Steshenko
On Thu, 21 Sep 2006 12:16:25 +0200 Tomas Carnecky <[EMAIL PROTECTED]> wrote: > Clemens Ladisch wrote: > > Tomas Carnecky wrote: > >> The thing is, in my application I can't set period time to anything else > >> than 21333 and that is, well, kinda bad. > > > > Your application must be able to han

Re: [Alsa-user] strange period size behaviour

2006-09-21 Thread Tomas Carnecky
Clemens Ladisch wrote: > Tomas Carnecky wrote: >> The thing is, in my application I can't set period time to anything else >> than 21333 and that is, well, kinda bad. > > Your application must be able to handle any period size. > > Why does the period size matter at all? My app can handle that

Re: [Alsa-user] strange period size behaviour

2006-09-21 Thread Clemens Ladisch
Tomas Carnecky wrote: > The thing is, in my application I can't set period time to anything else > than 21333 and that is, well, kinda bad. Your application must be able to handle any period size. Why does the period size matter at all? Regards, Clemens ---

Re: [Alsa-user] strange period size behaviour

2006-09-20 Thread Tomas Carnecky
Lee Revell wrote: > You are mixing up period_time (which is in microseconds) with > period_size (which is in frames). period_time defaults to 125000. > > Why do you want to use an .asoundrc at all? > I want to set period size or time to a value so that the buffer is 16kb - because that's what

Re: [Alsa-user] strange period size behaviour

2006-09-20 Thread Lee Revell
On Thu, 2006-09-21 at 03:24 +0200, Tomas Carnecky wrote: > Without a .asoundrc, alsaplayer gives this: PERIOD_TIME: (21333 21334) > I can play several sounds at the same time through dmix. > > But, with a .asounrc that has the following: > > cards.ICE1724.pcm.dmix.period_time 1024 > > (note that

[Alsa-user] strange period size behaviour

2006-09-20 Thread Tomas Carnecky
Without a .asoundrc, alsaplayer gives this: PERIOD_TIME: (21333 21334) I can play several sounds at the same time through dmix. But, with a .asounrc that has the following: cards.ICE1724.pcm.dmix.period_time 1024 (note that 1024 is the default value for dmix, so that shouldn't change anything),