>Given that, technically, I can use ALSA with a user-space device driver, am
>I right in thinking that the user-space driver must have a license that is
>GPL compatible?
>
>Or is a closed source driver allowed?
alsalib is released under the GPL. hence, any applications that to use
it must be unde
>> alsalib is released under the GPL. hence, any applications that to use
>> it must be under the GPL. since such an application would clearly be
>> utterly designed around the alsalib and alsa kernel API, you could not
>> use dynamic linking to circumvent this.
>
>As alsalib is released under the
>I need to record at least 16 channels with no phase error between channels.
>
>Is it possible with alsa to start (trigger) two cards or two ADAT ports on
>same card such way, that first samples from both devices are exactly from
>the same moment? Devices are of course word clock connected. Time/p
>I would like to build a "music machine" using oskit
>http://www.cs.utah.edu/flux/oskit
>I would like to buy a professional-quality soundcard that has a development
>kit available, and at this stage I do not car about signing an NDA or paying
>for the kit, as long as I can get the docs for the c
>> but its still possible that if an interrupt occured at the wrong time,
>> the delay between issuing the two start instructions could be
>> sufficient to mess them up. its hard to work around this, though there
>
>Trying to do this in user space is mad. It should be done in drivers.
it *IS* don
>> its not that simple. you have to make sure that the driver software
>> state is up-to-date when the h/w starts. you can't just issue out()'s
>> and then pick up the pieces later. you have to make sure that the
>> driver infrastructure is ready to start processing interrupts, etc.
>
>Isn't this
>What does a period mean when setting hwparams? If I want to play a 16 bit
>stereo stream, what should I enter in the function
>snd_pcm_hw_params_set_period_size and snd_pcm_hw_params_set_periods?
its the interval between interrupts from the hardware. this defines
the input latency, since the CPU
>is anyone out there working on the seasound solo driver? if not, what
>can i do to start work on it myself? i haven't written a driver before,
>but have some experience with programming languages and would like to
>learn.
i'm pretty sure its just built on the ice1712 chipset. you'd have to
get i
In message <[EMAIL PROTECTED]>you write:
>> > The only thing I can think of is that the sound card clock is drifting
>> > too.
>>
>> Do you mean the drift as the difference between the "real" wall-clock
>> time and sequencer ticks? Or between the sequencer time and ticks?
>
>The sequencer clock
>Ok, I think I understand most of it, certainly that my application can do
>without it (and I tried and it works without). But what is a possible use
>of this kind of settings? Is it only of interest to low-latency
>applications?
it will affect how much work the CPU does. if you set the period si
>> Also, is there a driver that uses ISA programmed I/O that I could
>> examine? All the ones I've looked at use DMA. Is there some way to use the
>> alsa-kernel DMA stuff without having a DMA channel?
>
>Sure, everything what you need is emulation of DMA transfer. Transfer the
>required count of
>What do the callbacks do in snd_pcm_ops_t:
the best answers can be found by looking at similar drivers, or even
dissimilar drivers. i wrote two ALSA drivers that way.
> open
someone has called snd_pcm_open() and the named device has resolved to
include this h/w device. you should take ow
>We need an option to aplay that lets you set sched_fifo and a priority so
>that those of us using a ll kernel can get it right and we won't see xruns
>because of lack of scheduling.
>
>Do we have a -Z? how about a -R?
mustajuuri has a nice executor/wrapper for this that uses capabilities
and is
>What in the world are you talking about?
you don't want SCHED_FIFO handling in every program. you want a
utility like:
zsh> rtfifo your-command-here
which would acquire CAP_RESOURCE, then set its scheduling policy to
SCHED_FIFO, then call mlockall(2), and then exec your-command-here.
>I'm sure that if the gurus on the list started joining, the conversation
>would pick up.
i don't know if i'm a guru, but i do know that i don't do irc. the
last time i did anything like that was on bitnet in 1986. i'm done.
--p
___
Alsa-devel mailing
>I'm new to this ASLA stuff so this is a newbie question.
>
>In the 0.9 versions of alsa, some of the interfaces have changed. Is
>there a document that describes porting software from 0.5 versions.
>
>I particular I see 3 types that are no longer there. What are the
>recomended replacements???
I
>I have released a 3D audio library LGPL @ sourceforge :
>http://mffm3daudiolib.sourceforge.net/
its quite possibly very cool. its too bad that my 28.8kB/sec modem
doesn't allow me to view the page in less than several minutes, and
viewing it in lynx provides me with a fairly useless page that te
>I wonder how it was designed without at least a bit of documentation on
>what everything does.
you will find that most skilled coders can write thousands of lines of
code without a design document. not to say that this is a good thing,
however. in the case of ALSA, we've been an iterative proces
I really liked "A Book on C". I'm not sure if its still in print.
>For low-level, kernel-specific stuff, get "Linux Device Drivers" by
>Rubini and Corbet. You want the second edition; it's an O'Reilly book
>with a _brown_ cover (the old edition has a purple cover). Fantastic
>book, and it cove
>Is there any documentation on ALSA 0.9.x? Also, will the "preliminary"
>documentation on ALSA 0.5.x ever be updated?
The equivalent documentation (i.e. the list of functions with
descriptions) exists in the source and can be generated with
doxygen. It is not currently available online. There has
>I have noticed that ALSA tends to use mutexes a lot
>for its internal locking. Has anyone ever considered
>using rw-semaphores instead? The biggest impact would
>probably be to the /proc filesystem since it would
>allow multiple concurrent readers, but I suppose that
>it might also reduce other c
>Off the top of my head, I can't see why developers
>would choose mutexes over rw-semaphores. If you take
>the write-lock then you have exclusive access to the
>resource, exactly as with a mutex. There's nothing
>that says you can't read the resource as well, and so
>I don't really understand your
>Not sure if you saw my question about whether there is some way to
>determine where in the kernel a hold up occurs. How does Andrew Morton
>check those things? Seems like a tool to determine what driver, program
>or kernel routine is causing latency spikes would be a useful tool.
andrew himself
>A good news: after several tries and hacks, I got 1msec latency.
from what card? or is this using the h/w pointer location directly,
and not relying on interrupts ? i don't know any cards that can
provide 1msec output latency by using interrupts ...
--p
___
>>
>> Now what is our definition of latency, exactly? 256 byte periods =
>> 1.45ms between interrupts, according to simple calculations - so we're not
>> at the sub-1ms level yet, at least :)=
>>
>
>Right.. I've used the word really confusing.
>The latency is of course 2 (up to 3) msec.
i've h
>Ok. Sorry to be so pedantic, it must be some small small error, but...
>
>1. what does snd_pcm_avail_update() do and what does its return value mean?
it checks on the h/w pointer to discover how much data/space is
actually available. it returns the space (in units of frames). if
there has been
>How do duplex RAWMIDI work? Are they capable of both input and output
>functions? What is the point of having such a device when the input and
>output could be opened separately?
does it occur to you that perhaps they can't, for h/w related reasons?
and anyway, which version of ALSA are you u
>pcm.rme1_2 { // should represent channels 1- 2
> type plug
>pcm.rme3_4 { // should represent channels 3- 4
> type plug
as little as i know about this stuff, i do know that that won't
work. you need to use the "type share" i believe, but as i've noted
before,
>First, have there been any clock modifications to the rme9652, or
>potential problems cropping up over the last few months that would make
>word clock sync not possible?
no. word clock sync works fine here.
>What kind of cabling and terminators should be used? Can one connect the
>BNC connector
>what is time code then?
the breakout cable can receive proprietary Alesis ADAT TC
information. its a totally different signal and has nothing to do with
sample sync. i can't repeat this too often.
>Sometimes it says the clock source is word clock and in () it puts no
>signal, and sometimes it d
>> right. you can choose word clock, but if there's no word clock source,
>> it will default back to the internal word clock source (the h/w does
>> this, not the driver).
>>
>Does the driver get notified of this?
no, its implicit in the operation "set clock source to word clock". if
you do tha
>there is something wrong with either the pcm.c example or with the
>documentation in alsa-lib/src/pcm/pcm.c.
>
>the documentation says about snd_pcm_mmap_commit:
>
> 'To call this with offset/frames values different from that returned by
> snd_pcm_mmap_begin has undefined effects and it has to
here's a better version (i think):
* You should pass this function the offset value that
* snd_pcm_mmap_begin returned. The frames parameter should hold the
* number of frames you have written or read to/from the audio
* buffer. Each call to snd_pcm_mmap_begin() may be followed by a
* series of z
>I've been experimenting with recording at >16 bit depths (Midiman Audiophile
>and current ALSA CVS).
been doing it for a couple of years now :)
>Since 24-bit files are a right-royal-pain and the ALSA hw device for ice1712
>uses a format of S32_LE, I've been recording to 32-bit .wav files, usi
>> the hw params include information on both the sample bit width and
>> `msbits', which tell you how (for example) the 24 bit
>> data is packed into 32 bits.
>
>It is however not clear to me that this is encoded in the header of a normal
>WAV file (unless bits_per_sample should be 24 for snd's c
>Yes, while we have the mmap_begin function limiting the transfer count and
>application knows how many samples should be filled, the reducing the
>counf of channel is really not necessary. I think that it would be better
>to avoid to do this by programmers, because we can use the mmap_commit
>siz
>No, NO...
>
>Never do this mistake, you cannot use mmap_begin result to know how many
>frames are available: it simply does not work with non HW PCM.
>
>You *have* to use snd_pcm_avail_update() for that.
I was simplifying my loop for pedagogical purposes. Of course I use
snd_pcm_avail_update() i
> avail = snd_pcm_avail_update(pcm);
> while (avail > 0) {
> frames = min(avail, block_size);
> snd_pcm_mmap_begin(pcm, areas, &offset, &frames);
> process(frames);
> snd_pcm_mmap_commit(pcm, offset, frames);
> avail
>Jack has some infrastructure (cvs, mailing lists, home page,
>documentation, etc.) that permits to track its evolution?
it should have all these things. alas, with the current availability
of time, plus the impending uncertain future of SourceForge, its not
clear how best to go about this. Are y
>It would be very interesting to see ALSA implementing device-specific
>hardware queuing for multiport MIDI devices - lot's of the "professional"
>ones have it nowadays. With different top-secret protocols of course.
yes, i suspect its going to cause as much disruption to ALSA's MIDI
side as the
>> keep in mind that this is likely to be no more efficient (and possibly
>> less) than using esd or artsd. it still involves un-optimized IPC with
>> a server process.
>
>How can you affirm that is a mistery for me: async notification, poll
>and shared memory will make the difference (a big diffe
>To be more specific I'm referring to a function(?) called type share as
>opposed to type hw. PD mentioned last week that Abramo had implemented
>it a while ago and mentioned that it did this for cards that do not have
>support for multiopen.
>
>He also said that AFAHK Abramo is the only person wh
>> i have this card, and as i posted on lau, it does not support multi open.
>> but my ymf744b card does. if you "cat /proc/asound/card?/pcm?p/info" you
>> can see how many h/w playback streams you have by looking at
>> subdevices_count. subdevices_count = 1 on the audiophile (ice1712), and
>> 3
Jaroslav:
I posted this a couple of months ago. This patch it critical to preventing
mmap-based applications from misbehaving with the hammerfall. What is
shown below is a completely new version of the hw_pointer routine for
the hammerfall. it doesn't completely eliminate spurious ptr values,
but
>> Hmm sounds like h/w problem, then..
>> It's interesting to know where the data is contaminated, whether on
>> the driver level or transfer between capture and playback on
>> user-space, or what else..
>
>I would say on driver level: I write the data to disk right after the
>snd_pcm_readi call.
don't apply it!
i was working on one the earlier revision rme9652 cards tonight, the
first time in a long time. the patch i sent does not work there. i
spent some time thinking about this, and i realized that there is only
one correct solution
rme did not design their hardware to be used wit
this patch makes ALSA treat the hammerfall the exact same way that
ASIO does, which makes sense to do given RME's claims about the card.
the hw pointer is reduced to essentially a 1 bit value - its either at
the start of the first period or at the start of the second. there are
no values between
>I run the alsa-lib/test/latency.c test in poll mode,
>but the problem is the tick time, which is at 100 Hz:
>
>snd_pcm_hw_params_get_tick_time(params, NULL) = 1
>
>What am I doing wrong?
using poll mode and/or not making the RTC available as a timer via
Takashi's kernel patch.
--p
>My ALSA output driver for my app has some fairly serious issues - when using
>async (callback) mode, I can't get the sound system to restart gracefully,
what do you mean by async mode? i'm one of the more experienced ALSA
programmers, and i have no idea what you're referring to. is this ALSA
0.9
>> what do you mean by async mode? i'm one of the more experienced ALSA
>> programmers, and i have no idea what you're referring to. is this ALSA
>> 0.9.X, or 0.5.X?
>
>The async notification is a new feature of the 0.9.X API. The ALSA drivers
>can generate SIGIO signal when the poll condition is
>> this patch makes ALSA treat the hammerfall the exact same way that
>> ASIO does, which makes sense to do given RME's claims about the card.
>
>I've added your code and it is the default behaviour. The experimental
>pointer code is still there, and it can be enabled using
>the 'snd_precise_ptr'
>I am wanting to know wether there is some way I can get rid of these < 1ms
>XRuns ?
if they are not caused by your application's design (i haven't looked
at it closely), then the answer is no, at least not without:
1) running it SCHED_FIFO, with mlockall() called
2) running a low-latency
>I am wanting to know wether there is some way I can get rid of these < 1ms
>XRuns ?
do note, hwoever, that it could easily be your application desing that
is the problem.
this:
>while ((frameCount=dd->audio.readAudio()) && dd->audio.active){
> int written;
>written=snd_pcm_writei
>i suspect that you may not be writing chunks of the correct size to
>the PCM device. by delaying for 1000msecs when you have no idea what
sorry, i was forgetting what snd_pcm_wait() did. even so, this is
still a design that could cause problems, i think.
--p
__
>Does anyone on this list know how to setup .asoundrc to allow an app
>to monitor the audio ouput on ANY pcm device/subdevice like in the
>0.5.x tree? (snd_pcm_loopback)
IIRC, there is no loopback API in 0.9x. I could be wrong though.
personally, I think that if you think far enough ahead, you
>Well, it doesn't seem to be completely okay... I occasionally get the error
>"Initial write error: broken pipe" and it just shuts down (well, it actually
>just hangs because the incallback mutex is never cleared - I need a timeout
>in there) the callback if things get too much for the poor thing
>I would say that the realtime capabilities of alsa were fine.
>I help write/develop xine (xine.sf.net) which is a media player for linux.
>alsa provides us with perfect audio to video sync.
>
>Our only requirement is to know how many samples are currently in the audio
>buffer.
>So, if we send ano
>> I was not aware of the method which ALSA employed to generate the callback -
>> I just expected it to _work_ like it does in Win9x (optimistic, it would
>> appear). Okay, ALSA async is dodgy... I won't use that mode, then. But at
>> least Jaroslav has fixed it so it doesn't crash on shutdown
>> >did also notice when running the pcm example in async mode, if I started
>> >moving scrollbars and the like in my KDE environment, continuous glitches
>> >came into the audio.
>> no suprise there. i imagine you were handling the "audio device ready"
>> SIGIO signal in the same thread as the GU
>> >Our only requirement is to know how many samples are currently
>> in the audio
>> >buffer.
>> >So, if we send another sample to the buffer, we can calculate exactly how
>> >long it will wait in the buffer before being played.
>> >
>> >For what type of real-time applications would this approach
>Well I don't think alsa has ever said it could do that, or has ever said it
>wanted to.
true. i'm not saying its ALSA's job. but its a job that something has
to do.
>If one wishes to sample sync audio from two different programs, there has to
>be a method for comparing the two streams to see if
>I don't agree here that ALSA convers only HAL model. We have great plugin
>system, which allows to build anything you need. Application code doesn't
>know, if it is referencing the real audio device or a pseudo device or
>a logical device created by an arbiter application for sharing and/or
>mixi
>Using callbacks is a bit unuseable in the unix systems, because it doesn't
>allow multiprocess communication. Using RPC has same cost like poll,
>so I don't see any benefit here.
not true.
http://jackit.sourceforge.net/cgi-bin/lxr/http/source/engine.c
its not simple :)
--p
__
>Using callbacks is a bit unuseable in the unix systems, because it doesn't
>allow multiprocess communication. Using RPC has same cost like poll,
>so I don't see any benefit here.
also, just to be clear: sure, there's still poll(2) involved. the
point is not that its cheap (this is what Abramo an
>> sorry, but thats not running in sample sync. thats "chasing sync". if
>> one of them "drifts", the others follow. running in sample sync means
>> that they never drift. its like the difference between word clock and
>> a time sync signal like MTC or SMPTE. the former avoids any drift by
>> havi
>So the assumption here is that there is only one drain/output device, and
>all sources are kept in sync with the single drain device.
>Your solution would fail if there was more than one drain/output device.
>I.E. Two audio cards.
just to clarify my last answer. yes, JACK does assume that there
>I still don't understand the difference. Seeing jack code, there is
>nothing new. You are using threads, shm for multiprocess communication
>and callbacks for the final communication between the application audio
>code and arbiter client. Can I see the global JACKs scheme which beats
>this scheme
>> aserver doesn't provide a frame count to the client client telling it
>> how much to do. when the client returns from poll(2), it can find out
>> how much space/data is available, but at this time, that has no direct
>> correlation with how much it should actually process. i can't see that
>> i
>> i spent some time last week porting a nice little app called RythmnLab
>> to use JACK. it used the same kind of design that so many linux audio
>
>Where can we get RythmnLab?
the original is linked from dave phillips' pages. my port (which i
will rename, since i rewrote most of it to use gtkmm
>I think I know the source of Maarten's question. In the
>alsa-lib/test/latency.c the "readbuf" routine has the following code:
>
>do {
>r = snd_pcm_readi(handle, buf, len);
>} while (r == -EAGAIN);
>
>For the non-blocking case this would take up 100% of the CPU tim
>I don't agree with Paul that the latency.c test program is not a good
>example for testing and showing the capture -> process -> play circle
>required by some applications.
applications that do this will need to be multithreaded if they have
any UI at all (i.e. anything involving real-time cont
>with ALSA's snd-pcm-oss emulation module. If you get good results
>with that, it'll be the ALSA library or the ALSA functions in the
>latencytest programs which are screwing up, not your system.
latencytest+ALSA on my machine has decent latency down to <2ms. ALSA
*in general* is not responsible
i just uncovered a subtle bug in the audioengine inner loop.
it might not affect you, but then again, if it does, it will be nasty.
when i wrote audioengine, the idea was to guarantee that all clients
would never be asked to process more frames than was specified in the
last call to their set_blo
>You are speaking about higher abstraction level on the one hand and on
>the other, you want to control everything. But okay, I see the potential.
No, I only mentioned the library of conversion functions because some
people will feel a need for them in a JACK-like system. Personally,
all my appli
>> If nobody has comments, I'm ready to prepare a whole patch for Linus
>> against the actual 2.5.1pre code.
i think we need to be just a little careful how we approach this. i
get the sense that many people feel that although ALSA has a much
better design than OSS, they also feel that the actual
>I monitor creative drivers, and they have not any extra features
>(except missing an user space linker for FX8010 DSP - different design of
>microcode maintaince). ALSA offers the wavetable synthesis for EMU10K1 for
>months, while the creative driver offers only PCM & mixer capabilities.
so do y
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
jaroslav - this happens on several different "consumer" audio
interfaces. an application waiting in poll(2) will return, but
snd_pcm_avail_update() and snd_pcm_mmap_begin() will report only a
single (or very small number of) frames available. do you consider
this an error, or should an application
>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;
>
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
>> 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
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
>> 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
>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
>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
>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
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
>I saw you pointing to the problematic usage of mutex with
>ringbuffers a couple of times now. In the most recent case
>you mentioned a solution of yours without mutices (sorry,
>I can't find the reference anymore ... probably was on LAD).
>
>To me it's not clear why protecting a ringbuffer with a
here are two consecutive return-from-poll situations:
--
poll events = 0x4, checking capture avail
capture: hwptr = 193 apptr = 128 <= OK, hwptr += 64, apptr += 64
checking playback avail
playback: hwptr = 193 apptr = 256 <= OK, hwptr += 63, appptr += 64
hw avail: c:6
>> ok, i'll go get my daughter from school and think about this on
>> the way there and back. maybe full duplex poll is required, but it
>> seems awfully heavyweight for full duplex h/w where the playback and
>> capture streams should be running synchronously.
>
>In this case you'd have both reven
>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
>gcc -O2 -Wall -fPIC -c bfio_alsa.c
>ld -shared -o alsa.bfio bfio_alsa.o -lasound
i don't think you can't build shared libraries like this unless you
have the right kind of object for libasound, and i'm not sure that
*.so is not the right kind of object.
it seems that you're trying to express a
ok, i added "duplex polling with retry". i am now seeing interesting
behaviour that i need to understand (and correct):
1) the behaviour (see trace below)
2) summary
if capture is not ready at the same time as playback, returning to
poll to wait for capture often works. but not always. sometimes
yeah, as usual, i forgot the insanely elegant but obscure way that
poll works inside the kernel ... poll_wait() doesn't block the task.
continuing my explorations.
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listin
this is a trace generated with printk, rdtscll and some post-perl
munging. the cycles were trimmed to the significant range. i have
added commentary.
i am tracing 3 functions in the ALSA kernel code:
snd_pcm_capture_poll
snd_pcm_playback_poll
snd_pcm_hw_ptr_interrupt
both poll routines ha
ok, i added more printk's in the trident driver to track exactly what
the interrupt sequence is.
and what do you know ... if i add just one printk at the top, this
doesn't stop things going wrong. if i add two printk's to tell me more
about the nature of the interrupts, suddenly, everything works
>It's true that the Trident IRQ acknowledge is probably broken at some
>level. I found, with small periods, that Trident chip acknowledges
>the IRQ more times, so it could be possible, that some interrupts are
>lost, too. You can look for the spurious word in the Trident interrupt
>handling routin
the problem with the trident driver is definitely the spurious
irqs. the driver doesn't print all such spurious interrupts, which is
why they don't show up in my logs. when i changed my trace code, its
became clear that they definitely occur quite often.
the problem with dropping "spurious" irqs
[ i thought sent a message about this earlier, but didn't see it ]
i was looking at the "full duplex poll" code that jaroslav provided
for josh. i noticed that it doesn't expect or require to find that
read+write are possible at the same time.
do we have any expectation of generally supporting s
1 - 100 of 798 matches
Mail list logo
