On Wed, 2001-11-28 at 05:47, Paul Davis wrote:
>
> do you think this is possible/likely? if it is, do you think that its
> the job of the low level driver(s) to handle this? otherwise, its hard
> for me to see how an application (or library) can handle this
> efficiently in any full-duplex sit
>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 remo
PROTECTED]>
Cc: "Abramo Bagnara" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: 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, th
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.
>
> --
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 a
vis
> Sent: 28 November 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:
> >
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 f
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
>I don't know all about mmap, but why does one need to poll.
>I would have thought that a callback with info on how many samples it wants
>would be a better way.
there is no generalized mechanism for the kernel to call userspace code.
POSIX signals are the canonical examples of such a thing, whe
>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 na
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 bette
; Sent: 28 November 2001 16:39
> To: James Courtier-Dutton
> Cc: Jaroslav Kysela; [EMAIL PROTECTED]
> Subject: Re: [Alsa-devel] more on that return from poll(2) issue
>
>
> >I don't know all about mmap, but why does one need to poll.
> >I would have thought that a
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 PROT
>I have not looked at the source code, but the SDL audio code uses callbacks.
>I think JACK also uses callbacks.
>
>Are these all doing "highly specific mechanism with lots of semantics" ?
no. they are userspace-to-userspace callbacks that are driven by a
return from poll(2), select(2), read(2) o
>> 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
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)
one last little bit of info. i added another printf to check on
something. it seems that with the trident driver, we are able to
return from a poll(2) on the capture device even when
snd_pcm_avail_update() tells us (as we expect) that there are *zero*
frames available. this seems like a clear cut
>> 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
Paul Davis wrote:
>
> solved. it turned out that "trusting" the driver was key:
>
> >> if (snd_pcm_avail_update(pcm) < period_size)
> >> break;
> >> count = period_size;
>
> this was the key point. sometimes when we returned
solved. it turned out that "trusting" the driver was key:
>> if (snd_pcm_avail_update(pcm) < period_size)
>> break;
>> count = period_size;
this was the key point. sometimes when we returned from poll(2),
snd_pcm_avail_update
>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)
> break;
>
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 20
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 the
> "upper limit". the period size is 2048 fr
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 the
"upper limit". the period size is 2048 frames, the buffer size is 2 *
period size. the fi
24 matches
Mail list logo
