On Wed, 28 Nov 2001, Jaroslav Kysela wrote:
On Tue, 27 Nov 2001, Paul Davis wrote:
enclosed below what happens when using ALSA, mmap mode and poll(2) on my
trident card at 44100. the value of contiguous is the value returned
by snd_pcm_mmap_begin() having been passed a value of 2048 as
count = (avail / period_size) * period_size;
count = avail - avail % period_size;
is more efficient (at least on i386 and gcc).
thanks for reminding me. alas, there is still a problem. could it just
be a device-specific issue? its as if the snd_pcm_mmap_commit doesn't
work on the
On Wed, 28 Nov 2001, Paul Davis wrote:
non-continous transfers. The right loop, based on the period_size
transfers, should be like this:
poll();
if ((pfd-revents POLLIN) {
while (1) {
if (snd_pcm_avail_update(pcm) period_size)
true, except that we enforce this requirement at a different
level. you can't get a synchronous engine to run correctly if the
capture and playback streams are not usable in the same basic way.
or can you?
Yes, you can find the nearest transfer count for both streams.
Sure, that would work
I think that you can easily solve the problem of missing frames from
capture or playback simply calling poll a first time with both stream
and a second time with the missing one.
In this way you solve the problem without the busy loop.
--
Abramo Bagnara mailto:[EMAIL
I think that you can easily solve the problem of missing frames from
capture or playback simply calling poll a first time with both stream
and a second time with the missing one.
In this way you solve the problem without the busy loop.
thats true.
however, as we've seen, that wasn't the nature
Jaroslav, you wrote:
avail = capture_avail playback_avail ?
capture_avail : playback_avail;
/* here is very bad assumption, that all drivers are able */
/* todo full duplex with same period sizes, it would be
On Wed, 28 Nov 2001, Paul Davis wrote:
Jaroslav, you wrote:
avail = capture_avail playback_avail ?
capture_avail : playback_avail;
/* here is very bad assumption, that all drivers are able */
/* todo full
On Wed, 28 Nov 2001, Abramo Bagnara wrote:
I think that you can easily solve the problem of missing frames from
capture or playback simply calling poll a first time with both stream
and a second time with the missing one.
In this way you solve the problem without the busy loop.
That's
2001 13:47
To: Jaroslav Kysela
Cc: [EMAIL PROTECTED]
Subject: Re: [Alsa-devel] more on that return from poll(2) issue
non-continous transfers. The right loop, based on the period_size
transfers, should be like this:
poll();
if ((pfd-revents POLLIN) {
while (1
after hacking both the kernel driver and alsa-lib, this is the view
from user-space. each block between is single return from
poll(2). i added code to print the values of the hw_ptr and appl_ptr
from within alsa-lib.
---
hwptr = 65 apptr = 0
hwptr = 128 apptr = 64
hw
On Wed, 28 Nov 2001, Paul Davis wrote:
after hacking both the kernel driver and alsa-lib, this is the view
from user-space. each block between is single return from
poll(2). i added code to print the values of the hw_ptr and appl_ptr
from within alsa-lib.
---
: Wednesday, November 28, 2001 6:08 PM
Subject: Re: [Alsa-devel] more on that return from poll(2) issue
Yes, you can find the nearest transfer count for both streams.
Sure, that would work but its not of much interest to me right
now. Thats really just telling a user you asked for N frames per
I tried to run the ardour-package that Takashi Iwai provides on
ftp://ftp.suse.com/pub/people/tiwai/alsa9-packages/7.3-src/
but it seems that exactly due to this it won't run. Too bad, ardour
look very very promising on the web-pages!
I respectfull request, with great vigor, that Takashi remove
14 matches
Mail list logo
