pgraded to Linux 2.4.10 and the patch *still* breaks
> the build! Maybe Linus hasn't integrated the very,
> very latest devfs into 2.4 yet, but that extra
> argument is not present in the current devfs function
> prototypes.
This is already fixed in current CVS.
--
Abramo Bagnara
possibility to have multiple mmap_commit for one mmap_begin).
I know that this is harmless on most types of PCM but it might not be
true for all PCMs.
Also I don't see the benefits to split the commits.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
_mmap_begin(pcm, areas, &offset, &frames);
and then reduce the number of frames to call snd_pcm_mmap_commit with.
Perhaps it's useless, but this is how I designed this API.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Ope
Jaroslav Kysela wrote:
>
> On Thu, 1 Nov 2001, Abramo Bagnara wrote:
>
> >
> > I have to partially disagree, nothing inhibits to do:
> >
> > frames = buffer_size;
> > snd_pcm_mmap_begin(pcm, areas, &offset, &frames);
> >
> > and then r
tc.) that permits to track its evolution?
I ask that because from your words it seems something like Klein bottle:
it's undistinguishable what's inside and what's outside.
Here I've laaga-0.2.3.tar.gz, but it seems a lot incomplete to me.
--
Abramo Bag
gt; limit the amount of data it indicated was available.
Then I deduce everything is ok? Paul? Tim?
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolog
to use it
> rather than AudioEngine. This will act as a suitable inducement for me
> to work out the problems and finish it off.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
async notification, poll
and shared memory will make the difference (a big difference, believe
me).
The main problem I have is to find time to complete pcm_mix and to make
some changes to pcm_share.
SuSE support was invaluable, its lack for so many months has made
everything harder and slower for
nd
snd_pcm_mmap_commit you will not note it.
May be that the reason of what you're seeing?
AFAICS this is not a problem solvable with a definitive solution, but
the fail window may be restricted (although I'm not sure it can be done
without some loss of efficiency).
--
Abramo Bagnara
m user
- asserts (that can be disabled in production releases for efficiency
reasons) for program bugs (although outside of alsa-lib).
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel B
nd
snd_pcm_mmap_commit you will not note it.
May be that the reason of what you're seeing?
AFAICS this is not a problem solvable with a definitive solution, but
the fail window may be restricted (although I'm not sure it can be done
without some loss of efficiency).
--
Abramo Bagnara
m user
- asserts (that can be disabled in production releases for efficiency
reasons) for program bugs (although outside of alsa-lib).
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel B
e):
1) make snd_assert call assert
2) ignore all snd_assert (for efficiency benefits)
3) make snd_assert write a warning and do an action (now impossible)
4) same as 3 without the warning
However I'm still convinced that 1) is the right default choice.
It's also very impo
e):
1) make snd_assert call assert
2) ignore all snd_assert (for efficiency benefits)
3) make snd_assert write a warning and do an action (now impossible)
4) same as 3 without the warning
However I'm still convinced that 1) is the right default choice.
It's also very impo
vers
> can generate SIGIO signal when the poll condition is accomplished.
^^^
Nope, the signal is generate every period, when period elapses.
It's
> nice feature to avoid using pthreads.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera
ll statements you see on this (and
other) lists (my comments too, of course).
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - I
e important, you're also a tough tireless supporters of your idea.
However to bury us under an avalanche of words is hardly a way to
convince us (take this as a prayer to write shorter message when you
want to show your arguments).
--
Abramo Bagnara mailto:[EMAIL PROTE
edback has been given and nobody else has exited this
> > discussion convinced for a model or another.
>
> Ahem, _nobody_?
I've said *almost* nobody (and note this is only a quantity
consideration and definitely not a worth one)
--
Abramo Bagnara mail
t "not so quick and little" hack in kernel
> code :) Hmm, perhaps i'm wrong, we can change the code without too
> much rewrite.. Let me see..
>
> Anyway, if we use ALSA timer on pcm, we'll need an additional API call
> (or module parameter) for timer selection such as
not imply a "major" rewrite: the API and the kernel code has
been thought for that.
You need simply to have different snd_pcm_tick_set functions (see
pcm_lib.c).
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via
be defined in asound.conf?
Yes, of course. Only I'm not sure whether to have a default different
than system timer is sensible.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.6560
ack into
> poll after handling 1 period.
>
> thanks very much for pointing me in the right direction. this is
> great. for those not on jack-devel, we now have an N-channel capture
> client (it records from any set of JACK ports) plus alsaplayer working
> via JACK now.
--
Ab
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
In this case you'd have both revents set (with a lowlevel driver that
take care of that).
However I don't think this worth the effort: it's a small window.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.6
Note however that link is realized "as best as possible" then
you may have some microseconds between the start/stop of different
cards.
Q: Does multi PCM run in sync?
A: Yes, of course.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
dave willis wrote:
>
> On Thu, 29 Nov 2001, Abramo Bagnara wrote:
>
> > Q: with the ice1712 it is possible to run two or more cards in sync
> > A: Yes, if you're not thinking to share the same clock chip (i.e. some
> > drift is possible).
>
> why can'
>A: Yes, of course.
>
> so the multi PCM code now handles drift and corrects for it? that
> wasn't true some time ago (or so says the mail archive).
No, but it could (simply decrementing appl_ptr under the scene on all
PCM but the slower).
--
Abramo Bagnara
iven event may
happen).
This is the rule you need to remember.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project h
Tim Goetze wrote:
>
> Abramo Bagnara wrote:
>
> >Don't make this mistake: poll *have* to return immediately in *all*
> >cases where to wait is useless (i.e. when no non-user driven event may
> >happen).
> >
> >This is the rule you need to remember.
&g
ept pcm_share plugin),
Why you say that? pcm_share has been written with multithreading in
mind.
I've missed something?
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
4801
e come from? i was under the impression that
> poll(2) should timeout in those cases, not return immediately.
Common sense I'd say ;-) Why to wait for events that cannot happens?
The "Waiting for Godot" approach seems not sensible in CS.
--
Abramo Bagna
Tim Goetze wrote:
>
> Today Abramo Bagnara wrote:
>
> >Paul Davis wrote:
> >>
> >> >Don't make this mistake: poll *have* to return immediately in *all*
> >> >cases where to wait is useless (i.e. when no non-user driven event may
> >>
mentation wrong.
What are the reasons of this choice vs. the opposite one?
Are you sure that for each PCM type is always possible to commit *all*
frames or none? What happens if after a first partial transfer we get an
xrun?
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Oper
Jaroslav Kysela wrote:
>
> On Sun, 9 Dec 2001, Abramo Bagnara wrote:
>
> > Jaroslav Kysela wrote:
> > >
> > > On Sat, 8 Dec 2001, Tim Goetze wrote:
> > >
> > > > the doc to snd_pcm_mmap_commit says
> > > >
> > > >
Jaroslav Kysela wrote:
>
> On Sun, 9 Dec 2001, Abramo Bagnara wrote:
>
> > Jaroslav Kysela wrote:
> > >
> > > On Sun, 9 Dec 2001, Abramo Bagnara wrote:
> > >
> > > > Jaroslav Kysela wrote:
> > > > >
> > &
t call, they have
considered the early return of error a little benefit.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
mes
> committed in passed in pointer, or don't if NULL).
It's an idea from Jaroslav (and I don't dislike it *if* we do the same
for snd_pcm_write/read).
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
i'd say, yes i'd like to be informed about partial
> transfers.
>
> i'd make snd_pcm_mmap_commit return -errno in case of error and number of
> frames commited otherwise.
> that's approximately what read/write(2) do, and that's what i'd prefer.
Jaroslav p
rnel but I may be wrong.
If we couple this with Robert Love full preempt patch we should have a
reliable, "almost" warranted very low latency also during very high load
condition (and also on UP).
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
nfigure, and one time
> with f/c hardcoded to 64 in the hw setup so my code in all places believes
> it's going 2048, 1024, 512, ... -- not that it matters because i don't
> process any data. the one that's doing the 'real configure' crashes.
--
Abramo Bagnara
s continue to increase.
I don't think this is relevant wrt Jaroslav objection. He was not
proposing a *all-in-a-process* solution.
I believe that it's your CoreAudio like approach fallen in love he find
questionable (and I'm tempted to agree with him ;-).
--
Abramo Bagna
es 2.3msecs. the code doesn't suggest anything to me ...
It's hard to believe ;-)
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA projec
to adjust to get their audio configuration
> correct.
Are you serious about xml? Do you have smoked something weird?
A sensible alternative was something Lisp like, but I've preferred to
have something more user friendly.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
O
e
> and the system-wide file is more user friendly than lisp?
Notwithstanding I love Lisp so much, I have to say "Yes, definitely" ;-)
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna,
ot;hw" device.
Abramo don't say such stupid thing... Please make more attention before
to cite somebody.
plughw is only a shortcut.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
4
effect upon restarting the streams that suggests
> an out-of-sync hw-pointer.
Do you mean:
snd_pcm_mmap_begin
snd_pcm_drop
snd_pcm_mmap_commit
sequence?
If yes, it does not work, you need to call snd_pcm_mmap_begin again
after snd_pcm_drop.
--
Abramo Bagnara mailto:[
on is that between snd_pcm_avail_update call and
snd_pcm_mmap_commit we always put more data than hardware can read
(playback case)
Of course preemption can give us surpries, but that's life...
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
Fixed in CVS and thanks for verbose error detection.
Perhaps I'm missing something, but I strongly disagree with your recent
changes on CVS:
- if avail > buffer_size this means either played garbage (playback) or
overwritten samples (capture). The return of an error is perfectly
sensible (al
Kai Vehmanen wrote:
>
> On Thu, 21 Feb 2002, Abramo Bagnara wrote:
>
> >>> if (avail > pcm->buffer_size)
> >> Yes, this condition is faulty. It should be 'avail >= pcm->stop_threshold'.
> > - if avail > buffer_size this means either
the first reading it
looked awful at my eyes, but now I've seen the light.
Sorry for the noise.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014
s the only card
> with this problem ...
>
Actually they're two different cards, so they need to be treated as
such. I think that a module option is a suitable solution.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone:
control->value.integer.value[0] = source;
> control->value.integer.value[1] = destination;
> control->value.integer.value[3] = gain;
>
> snd_ctl_write (...)
>
> am i missing something really simple?
>
I suggest you to use the field index of struct snd
yped_
MATRIX_ELEM and this is a nonsense when already we have elements for
singleton controls.
Your question is: how to represent the info that a set of elements may
(should) be organized in a matrix?
We have already discussed that some time ago (about topology stuff,
etc., do you remember?) and w
ard specific code may solve all that easily.
We need to separate in our minds the _basic_ hardware access and
layout/display consideration. Kernel is for the former, libraries and
applications for the latter.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
pace code wants to flush samples to output, the
> snd_pcm_drain() function must be called before the snd_pcm_close() call.
>
> I hope that this change doesn't cause any problems in any
> application. Anyway, please, report all problems.
Please don'
t understand how it could be possible.
eh? You was living under a stone last years? ;-)
Kernel OSS emulation works on each cards (its behaviour is similar to
plughw). I played with xmms and rme9652 near two years ago.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
t for pcm_mix. Maybe one day I'll
find the time to finish it.
>
> > And the summing/normalization code in pcm_route.c treats the sample as
> > if it were unsigned.
>
> nice spot.
Be careful here. Use of signed vs. unsigned was an hard decision.
Can you point me exactly where
Clemens Ladisch wrote:
>
> Abramo Bagnara wrote:
> > min & max are interchanged indeed. My bad...
>
> Oh, there's no problem with using _max instead of _min -- I just
> noticed that the code for _max writes 0 for unsigned 16/24/32-bit
> values ... ;o)
Fixed
Clemens Ladisch wrote:
>
> Abramo Bagnara wrote:
> > Clemens Ladisch wrote:
> > > Abramo Bagnara wrote:
> > > > Use of 32/64 bits for 24/32 bit is wanted. Take in account that this
> > > > function is called on mix results (where I ne
Jaroslav Kysela wrote:
>
> On Tue, 9 Jul 2002, Abramo Bagnara wrote:
>
> > > > > > And the summing/normalization code in pcm_route.c treats the sample as
> > > > > > if it were unsigned.
> > > >
> > > > Be careful here. Use
o strong to Paul's words.
He own a big heart, but unfortunately a big mouth too, that he's often
unable to keep under control ;-)
Some portions of libasound *do* use pthreads.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Pho
Tim Goetze wrote:
>
> Abramo Bagnara wrote:
>
> >> >I think that the best behaviour is the current and it's also the
> >> >simplest to describe and to understand: poll/select never blocks when
> >> >there is nothing to wait.
> >> >
to what we as
> programmers expect, and sometimes program for. I would very much
> appriciate it, and I'm sure others will as well
Please understand that it's very hard to satisfy everybody and I'm not
sure it's a worthy goal.
That apart, I'm very interested to hear fur
tation, and it
> would seem silly to rewrite something that has already been written.
I doubt that some code edited last time more than 18 months ago and that
has never been completed or executed (the skeleton was from pcm_share)
may be of some usefulness for someone, but I'v
rcX and 1.0 is a professional suicide. However it's _your_ professional
suicide so... ;-)))
To resume, if you ask me, the answer is no.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
--- Begin Message ---
[ abramo: please forward to [EMAIL PROTECTED] thanks. ]
>I'm strongly c
he API between rcX and rcZ,
> this doesn't seem like much of a problem, anyway.
This is not true as far as I can tell. Jaroslav has made the changes an
option selectable at compile time. Consider also that he made a change
that break the compilation, while the case we are discussing is more
; more intuitive without exception.
As pointed by Clemens the current is the proper POSIX behaviour.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
-
current is the proper POSIX behaviour.
>
Perhaps you should reread Single Unix Specification, I quote
http://www.opengroup.org/onlinepubs/007904975/functions/poll.html
POLLIN
Data other than high-priority data may be read without
blocking.
POLLOUT
Normal data may be writte
turn any flags with
> these bits set. the issue, i thought, was what should write(2) do ...
No, the issue was about poll and write.
The point is that stream is in bad state wrt read/write, this is the
reason why poll should return POLLERR.
Clemens Ladisch wrote:
>
> Abramo Bagnara wrote:
> > > >No data may be read/written in current stream state in the case we are
> > > >discussing.
> > (...)
> >
> > The point is that stream is in bad state wrt read/write, this is the
> > r
xt switch, but the value is less accurate,
> +because ring buffer pointers are updated in kernel drivers only when
> +an interrupt occurs.
>
Wrong here:
1) snd_pcm_status_get_avail is only an accessor method
2) snd_pcm_avail_update call is *needed* for chained PCM (to call
snd_pcm_status
at? I'm thinking expecially to PCM chains and
pcm_share.
Ok, iff:
- Jaroslav agrees too
- somebody do the patch for write *and* poll, correct the documentation
and add a special paragraph explaining multithreading POV, correct
alsa-lib and test *all* the PCM classes
you'll have my vote (
Anders Torger wrote:
>
> On Wednesday 09 October 2002 09.52, Clemens Ladisch wrote:
> > Abramo Bagnara wrote:
> > > Clemens Ladisch wrote:
> > > > Abramo Bagnara wrote:
> > > > > The point is that stream is in bad state wrt read/write, this
> &
c and pcm are searched in this order
- if playback is specified pcmp and pcm are searched in this order
This would solve also the annoying problem of pcm that are valid only
for one direction and should not be used (or browsed) for the other.
--
Abramo Bagnara mailto:[
Takashi Iwai wrote:
At Wed, 07 Jan 2004 13:45:05 +0100,
Abramo Bagnara wrote:
Takashi Iwai wrote:
as written in my previous mail, it was a quick hack. and there is a
better approach.
I'd prefer the following approach:
pcmp.duplex {
type dmix
...
}
pcmc.duplex {
Takashi Iwai wrote:
At Wed, 07 Jan 2004 15:39:14 +0100,
Abramo Bagnara wrote:
I don't see your point, can you show me an example of what you mean?
AFAICS the only code that need to be changed is the PCM definition lookup.
there are two parts to be modified, snd_pcm_open_noupdate(
A API).
Under an "objective" point of view: would you really derive from the
comparison of the two equivalent alternative syntaxes the feeling of "a
big restriction"?
Technically they're quite the same.
--
Abramo Bagnara mailto
my mind: what about to have an OSS
emulation specific configuration?
Just like:
aoss_pcm_w.dsp0 dmix
aoss_pcm_r.dsp0 dsnoop
I think it's a far better solution and will leave native library intact.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
avail
3) leave critical area
4) copy from/to user using saved appl_ptr
5) reenter critical area
I've just checked and a similar mistake has been done too for PCM (and
other places?).
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
Jaroslav Kysela ha scritto:
On Sun, 1 Feb 2004, Abramo Bagnara wrote:
Jaroslav Kysela ha scritto:
Modified Files:
rawmidi.c
Log Message:
copy_*_user() function cannot be called from spinlock context
Index: rawmidi.c
===
RCS file
Abramo Bagnara ha scritto:
Jaroslav Kysela ha scritto:
On Sun, 1 Feb 2004, Abramo Bagnara wrote:
Jaroslav Kysela ha scritto:
Modified Files:
rawmidi.c Log Message:
copy_*_user() function cannot be called from spinlock context
Index: rawmidi.c
space on entry of function is not
empty how it can become empty if I ask for *nearest* value?
Obviously at least one configuration exists, then in the worst case such
value is returned.
Do you agree?
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
ier !
>
The correct plugin has already been written and available inside
alsa-lib.
The name is pcm_meter, it's lockless and perfectly integrated with ALSA
PCM chains.
A sample implementation for curses level meter is already available an
ert(obj);
> + memset(obj, 0, snd_pcm_hw_params_sizeof());
> +}
Why that _clear functions?
What's the expected semantic for "clear"?
When we designed new API I took in consideration them, but the lack of
usefulness and the ambiguity of sema
Jaroslav Kysela wrote:
>
> On Wed, 23 Oct 2002, Abramo Bagnara wrote:
>
> > Jaroslav Kysela wrote:
> > >
> > > Added ommited clear() functions
> > >
> > > Index: pcm.c
> > > /**
> > > + * \brief clear snd_pcm_hw_params_t struc
scopes.0 level
}
Then try:
aplay -D dsp0 file.wav
or the more complex
aoss realplay /u/music/real/music.rm
and you'll see amazing things ;-)
--
Abramo Bagnara mailto:abramo.bagnara@;libero.it
Opera Unica Phone: +39.546.656023
Via Emi
_pcm_avail_update() call
> is still mandatory before any I/O!!!
I really don't understand why you've added another ioctl and another
function to replicate in all PCM classes.
snd_pcm_delay existence is enough to implement that.
I'm missing something?
--
Abramo Bagnara
Jaroslav Kysela wrote:
>
> On Fri, 11 Oct 2002, Abramo Bagnara wrote:
>
> > I really don't understand why you've added another ioctl and another
> > function to replicate in all PCM classes.
> > snd_pcm_delay existence is enough to implement that.
&
y a wrap safe difference).
Are you sure you want to add another ioctl and another API function in
all the PCM classes just to avoid a subtraction?
--
Abramo Bagnara mailto:abramo.bagnara@;libero.it
Opera Unica Phone: +39.546.656023
Via Emilia Inte
Jaroslav Kysela wrote:
>
> On Sat, 12 Oct 2002, Abramo Bagnara wrote:
>
> > Jaroslav Kysela wrote:
> > >
> > >
> > > In this case, I propose to change snd_pcm_avail() to snd_pcm_hwsync()
> > > function with description: "synchronize r/w po
Jack O'Quin wrote:
>
> Abramo Bagnara <[EMAIL PROTECTED]> writes:
>
> > The correct plugin has already been written and available inside
> > alsa-lib.
> >
> > The name is pcm_meter, it's lockless and perfectly integrated with ALSA
> > PCM c
if you're insinuating I'm the one to blame I
believe you're definitely unfair.
Alternatively I should have to interpret this as angered knock on the
heaven's door...
"Success is simply a matter of luck. Ask any failure."
--
Abramo Bagnara
ctive community and
this mix is unable to found a supportable business, I might deduce one
or more of the following:
a) people are not skilful enough
b) community is not interested enough
c) project does not worth enough
Personally I'm trying to take back a) honestly and at best of my ability
avail = snd_pcm_capture_avail(runtime);
> if (runtime->status->state == SNDRV_PCM_STATE_DRAINING) {
What are you trying to do here?
What's the reason to call snd_pcm_update_hw_ptr when PCM is not running?
--
Abramo Bagnara mailto:abramo.bag
Someone can confirm this is the OSS conformant behaviour?
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
--- Begin Message ---
Hi Abramo,
I am working with
Takashi Iwai wrote:
>
> At Tue, 11 Feb 2003 14:34:36 +0100,
> Abramo Bagnara wrote:
> >
> > Someone can confirm this is the OSS conformant behaviour?
>
> yes. but the behavior of ALSA oss-emulation described below is
> correct because it really supports that samp
elevant the audible impact of this lack of correctness?
One thing I'm definitely sure is that this is the *perfect* approach for
pcm_share (at least now I don't see any drawbacks).
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
>
> ah, rewind take the appl_ptr back...
>
> regarding to another appl_ptr update:
>
> in pcm_lib.c snd_pcm_lib_read1/write1(), appl_ptr is set to 0 if it
> comes over boundary.
>
> appl_ptr += frames;
> if (appl_ptr >= runtime-&g
ze? At least I have seen it in cs4281
> driver some time ago. Is there any ALSA recommendation what value should be
> used for boundary?
runtime->boundary = runtime->buffer_size;
while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size)
1 - 100 of 132 matches
Mail list logo
