>On Wed, 2004-02-25 at 13:53, Takashi Iwai wrote:
>
>> - PCM mixing and software MIDI rendering in the kernel space are
>> evil. if you doubt it, ask on LKML :)
>
>So is low-latency, LKML people made that clear also about year or two
>back...
on the contrary. they've made it very clear that its
>Taken for granted that configuration space on entry of function is not
>empty
can this be taken for granted?
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD soft
>Are you planning to standardize such features or design a
>device-independent API for it? (And my manager wants to know which ALSA
>release this might get implemented in...)
Just a thought on your overall issues with ALSA over the last week.
The kinds of features you seem to expect from hardware
>And by that time, games will be even more demanding than before, and
>still want to use those cycles for itself rather than software sound
>processing, so just sitting idle waiting for the ultimate
>infinite-megahertz cpu, that can do everything in no time, gains nobody
>anything... at least our b
>At 05 Mar 2004 11:23:35 +0100,
>Simon Schampijer wrote:
>>
>> Hello,
>> I've got a Maudio Firewire 410.
>> Are you going to make also drivers
>> for this one ?
>
>so far, no ALSA developer works on it.
>
>> Or are there Problems with
>> Maudio or firewire???
>
>unfortunately, no hardware, no dat
>In any case, most of this can all be handled by software. The only stuff
>the hardware really need is the volume, frequency, direction to sound
>source, and any additional effects (such as reverb). Application
>software can deal with the rest.
i can certainly see the utility of such an API. howev
>What I basically did is investigated the current driver in Windoze for the
>carbus and it came up as a "generic cardbus interface." I was by now aware
>that the exact cardbus chipset is/was ENE C1410. So I did some searching on
>the Google for the driver and came up with HP's driver download page
>> Where can I get the complete list of controls which an audio codec has to
>> support.
there is no such list.
and lets get the terminology straightened out here before this goes
any further.
"codec" comes (in this context) from "coder/decoder". that maps
roughly to what is more properly referr
>$ measure -p ./out/x11.png -o ./out/x11.out -c 0 -f 1024 -n 2 -t 2
>I get this error message: "error setting freq 1024"
probably a permissions problem. try it as root.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutor
>open pcm, and get a handle.
>
>snd_pcm_poll_descriptors(handle, &pfd, err);
>
>Get a poll file scriptor in pfd.
>
>select(nfds, rfds, wfds, efds, tvp);
>
>Is it possible to use this call with alsa ?
select is generally deprecated in linux (linus says so!). but you can
use the same pfds in select
>> >open pcm, and get a handle.
>> >
>> >snd_pcm_poll_descriptors(handle, &pfd, err);
>> >
>> >Get a poll file scriptor in pfd.
>> >
>> >select(nfds, rfds, wfds, efds, tvp);
>> >
>> >Is it possible to use this call with alsa ?
>>
>> select is generally deprecated in linux (linus says so!). but you
>> select is generally deprecated in linux (linus says so!). but you can
>> use the same pfds in select as in poll (select is implemented in the
>> kernel using the poll code). the problem is interpreting the results
>> you get back (as noted recently for the dmix plugin).
>
>Nope, the application
>The problem is that I cannot get the mixer to have any "elements" (or=20
>"elems" as the alsamixer calls them) which thus makes the card un-openable=
>=20
>even with the alsamixer.
thats correct. the hdsp has no mixer that can be represented using
conventional mixer elements. there is nothing cor
>mainly the alsa guys who wrote the driver and know, how they access the
>bus system and the hardware, have to tell the pcmcia guys, who know,
>what's going on in the bus ... i CC'd this mail to the thomas
>charbonnel, paul davis and winfried ritsch, who wrote or maintain thi
>and it HAS do be a software issue, since at least on ico's and my
>machine, the hdsp works flawless with winxp ...
agreed. but its much more likely to be something about the cardbus
support under linux than the hdsp driver, and neither side (the
cardbus people or us hdsp people) knows the other
>I can't find any way to detect the running ALSA version, for diagnostic
cat /proc/asound/version
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologi
>Given that the alsa driv interrupts at period
>boundaries(which are defined in bytes), the tests i
>have carried out prove otherwise..i.e that the driver
>operates in millisecond power-of-two based periods.
on most PCI-based hardware, the audio interface interrupts every N
audio frames, where N i
>Well, if there is a way of monitoring these hex registers for various
>hardware in Linux I could try to compare their state upon initialization in
>Linux to that one in Windows (since in both situations they share the same
>IRQ, at least on my notebook) and forward this info to you guys.
>
>So my
>hope this is the right list to post: I installed to RME Pci Cards with
>a Multiface each. Running hdsploader finds and initializes both and
>hdspmixer can also get used with both cards using the card select
>buttons for card1 and card2. However after startup of jack, I only see
>18 alsa_pcm in and
>Does this mean that now one can channel ALSA-only aware apps directly to JACK
Yes.
>and if so, are there any penalties of doing it this way as oposed to using JAC
>K-aware apps (i.e. Sample-sync?)?
Yes, you lose sample-synchronous guarantees. Also, there *might* be glitches
in the audio output
>1) Open my Player, tune to my favorite station. Use my new device for
>audio output.
>2) do something like: dd if=/dev/audiocapturepcmout count=xxx | lame
>--output myfile.mp3
streamripper is a much better option for this. its specially designed
for this task. you are also talking about mp3->P
>When using OSS you can just do mixer ioctl's on the opened PCM fd.
When using OSS, you can't model a lot of the functionality present in
contemporary audio interface hardware mixers.
So there's a choice: a limited, simple API that fails to support card
features, or a complex API that over time g
>Do you plan any driver for M-Audio Firewire Audiophile? I have contacted =
>M-Audio=20
>French Support and post this request, they told me that M-Audio driver te=
>am=20
>(USA) had request you for this card to have a driver under alsa. Can you =
>confirm=20
>that?
Please note: since NAMM this yea
>in says under "known bugs":
>
> - 96kHz and 88.2kHz not accessible via PCM interface
>
>What does that mean? The card and driver does work in 96 and 88.2 kHz, I
>know that since I wrote the driver... but if there is some sort of bug,
>I'd like to know.
anders, i don't know, but it might mean t
>Kernel people: is poll() less effective than using SND_PCM_ASYNC and a
>signal handler for low-latency sound? I'm guessing it is, but there
at the risk of endlessly repeating myself, SIGIO is basically
useless. your handler executes in signal-handling context, and can do
very, very little. not e
>On Thu, May 06, 2004 at 09:49:31PM -0400, Paul Davis wrote:
>> at the risk of endlessly repeating myself,
>
>If you're being asked this frequently, I'd recommend adding some notes to
I'm not. I'm just a big mouth who always pipes up when SIGIO is mentioned
>Hi ,
>i'm trying to change the fragment size that the alsa
>driver is capturing/playing out. It's currently set at
>32 msecs(256 bytes).
>They are set in the runtime structure...
> runtime->period_max ...etc
>Could anybody tell me which file these parameters are
>set in the alsa-driver directory
> --- Paul Davis <[EMAIL PROTECTED]> wrote: >
>>Hi ,
>> >i'm trying to change the fragment size that the
>> alsa
>> >driver is capturing/playing out. It's currently set
>> at
>> >32 msecs(256 bytes).
>> >They are set in
>ok paul i had another look at the driver playback/capture tutorials. I have on
>e question.Do applications initialize and use a pcm_handle of the alsa driver
>when they begin interaction with it?Surely not
surely yes.
ALSA isn't structured the way windows seems to concieve of audio. We
don
i don't want to blow my moderator points this time, so get busy. there
is lots of confusion, mis-information and general cluelessness in the
responses so far. get to it, provide me with some stuff to moderate
upward ...
--p
---
This sf.net emai
>> > ALSA:
>> > cat /proc/asound/devices shows only one raw midi interface. This is on
>> > a two port device (but Muse lets me select either port). On the older
>> > alsa two devices show up on the listing.
>>
>> For multiport interfaces, the additional ports are available as subdevices
>>
>Hi, I'm trying to configure asound.conf to support "two cards as one"
>(but with 3, 8 channel cards!) as suggested in the .asoundrc doc. When I
>try to aplay the new device however I get:
>
>"ALSA lib pcm_multi.c:928:(_snd_pcm_multi_open) Invalid or missing
>schannel for channel 0
>aplay: main:
>1. Is there a good guide to porting applications written for 0.5.x to
there are no good guide to anything related to ALSA at this time.
>0.9.0? I'm trying to fix mpg123 to work with ALSA 0.9.0 natively;
>current stable version (0.59r) barfs when compiling all over
>audio_alsa.c.
the API in 0.9.
>I would like to help with the Hammerfall DSP driver.
>Is there any additional technical information? Could someone be so kind
>and forward it to me? The driver is easily readable, but it wouldn't
>hurt if I had the original documents still.
there are no documents. i have source code for a differe
>- In snd_hdsp_interrupt: The first four lines determine, why the
>interrupt was triggered (audio, midi0, midi1). Now the MIDI code further
>down does not use that information, but the MIDI status instead.
this is necessary because there is no interrupt for "output space
available" on the MIDI po
>For synchronization purpose I need the current time of my sound card
>(information on the sample that is currently played out might be
>sufficient / ADAT-Synch timecode) I did anticipate that the functions
the code to read the ADAT sync timecode is written, but is not
"exported" to a usable part
>[Summary of this message:
> I want to use alsa for timing of video frames, and want alsa to
> trigger a wakeup every .01466 seconds. But the documentation is
> sparse in this area]
>
>
>I'm attempting to use alsa-lib as a timing tool for a specialized
>movie playback engine. It _must_ tick/wa
>> ALSA is *a* sound library. There are lots of things that it doesn't
>
>I would really say: ALSA is *the* sound library (at least on Linux). Isn't it
>in kernel
>2.5+ ?
alsa-lib isn't in kernel 2.5, because its not part of the kernel.
alsa-lib doesn't contain any code to read or write audio fi
>> You see, if all apps are written to use the ALSA API, that's going to
>> be great for the purposes you have in mind, but totally awful for
>> those of us who want our audio apps to work in a sample synchronous
>> way and ignorant of the ultimate routing of their data. Many of us
>> don't think t
2 clarifications:
>It is not logical for every program to write support for esd, artsd, jack,
>alsa, etc. Programs should write to ALSA and let ALSA do software mixing if
>required. Windows provided this since DirectX (3?). Solaris provides this too
>(esd apparently doesn't block on Solaris).
>> Its the same PCI ID, but insmod segfaults...
>
>does the attched patch cure the segfault?
>but it doesn't mean that your card will be supported by it :)
takashi - thanks for this patch. i didn't understand that
snd_hdsp_free() could be called when no hardware was detected. now i do :)
--p
--
>> its also worth noting that it too is not immune from missing xruns,
>> but there isn't anything we can do about kernel/driver code that
>> blocks interrupts for an entire buffer :(
>
>I do not know how long an entire buffer is. I assume this will differ per
>card, but how small could the worst-
>I have just got a couple of the new RME Hammerfall HDSP9652 cards, and
>find that they are not supported by the snd-hdsp driver yet. The card is
>basically the same hardware as the other hdsp cards but with the io
>integrated on the card.
>
>I would guess that it will need a different firmware and
>> actually, it can't. if the user space application is delayed for
>> precisely 1 buffer's worth of data, it will see the pointer at what
>> appears to the the right place and believe that no xrun has
>> occured. the only way around this is to provide either:
>
>Well, but if you combine it with th
>> actually, it can't. if the user space application is delayed for
>> precisely 1 buffer's worth of data, it will see the pointer at what
>> appears to the the right place and believe that no xrun has
>> occured. the only way around this is to provide either:
>>
>> * h/w pointer position as
>I am currently taking the following approach: -
>Always prepare 2 audio hardware periods of sample frames in advance
>inside the user app.
>
>1) snd_pcm_wait()
>2) write()
>3) prepare new sample frames, then go back to (1).
for lower latency, you'd do:
1) snd_pcm_wait()
2) prepare new sample
>This is my personal preference. In this model the only service ALSA has to
>supply are:
>
>1. initial configuration/start/stop.
>2. mmapable DMA buffer
>3. fact and precise ioctl telling the current HW pointer in the buffer. If the
>card is not queried each time, then the "last period interrupt" t
>Sorry, it's not as easy as you've described. It's not possible to invoke
>any user code from the kernel code directly. There is a scheduler which is
>informed that a task has been woken up. It depends on scheduler when the
>task is really invoked. It's quite same as for the r/w model where the
>ap
>Am I sending these queries about the operation of alsa through the API
>to the right place ? I'm trying to use alsa for a real scientific
>application and I'm starting to worry it simply isn't ready yet.
the API is ready. the documentation is not. some of us have been using
ALSA to develop seri
>Ok, it's only simple example, that there are more solutions than Paul
>suggests. I fully agree, that the callback model is suitable for the
>perfect synchronization among more applications.
Let's be totally clear about this. its not just that the callback
model is suitable - the mserver model
>Ok, thanks for the line out help, and I think I understand how the
>matrix mixer works, and I can hear stuff through my monitors, but now I
>can't figure out how to get alsa input or output functioning. I can
>plug in my mic/pre and hear that through the monitors, and I can use the
>oss compatabi
>I have a STAudio DSP24 mkII and I have noticed that recent changes(after
>NOV 13) in the CVS creates an ICE1712 driver that locks up my kernel.
>Instead of just complaining about this problem I thought I might try to
>narrow down the location in the driver that is causing the lockup.
>
>Does anyon
>I started implementing a GUI for the HDSP matrix mixer using the fltk
>toolkit. I want to get as close as possible to the TotalMix RME
>application, thus I'm trying to implement hardware metering using the
>Peak and RMS HDSP registers. The peak value covers the whole int range,
actually, no. it c
>I guess another way of dealing with this kind of problem is to use a
>semaphore rather than a spinlock, and a workqueue: when the interrupt
>comes in, the call to snd_ctl_notify is put on the queue, where it will later
>be run in process context, and can safely take the semaphore.
can i get a poi
can the person who fixed their hdsp driver to work with the new 9652
please post a patch (c/o diff -u) here? i would like to get the fix
into CVS ...
--p
---
This SF.net email is sponsored by: Microsoft Visual Studio.NET
comprehensive developm
> From the keen-grasp-of-the-obvious department:
>This project would be a lot better off if there were
>better documentation, and (some) comments in the code.
>Why write the code if it's not going to be used?
>If it's not documented, it's not going to be used!
actually, i have to note that this is
> >actually, i have to note that this is not so obvious. there are *many*
> >people using ALSA. we've all sworn our way through the process.
> >there is *no* point in reminding this list about the need for
> >documentation. the current state is pitiful, ...
> > many folks seem to think there is a
> Where are the definitions for PCI_DEVICE_ID_XILINX_HAMMERFALL_DSP and
>PCI_VENDOR_ID_XILINX kept in the alsa code?
one of two places. either in the kernel source (if you have a much,
much newer kernel (2.5)) or at the top of either rme9652.c or hdsp.c
(there are conditional #define's there to
>3) When I boot I see the following message in /var/log/messages
>
>Dec 9 12:39:40 Godzilla kernel: Hammerfall memory allocator: buffers
>allocated for 1 cards
>Dec 9 12:39:40 Godzilla kernel: RME Hammerfall-DSP: no cards found
>Dec 9 12:39:40 Godzilla insmod:
>/lib/modules/2.4.19-1.ll/kernel/dr
>1) I am unable to turn down the volume with alsamixer. All the way up or
>down, the volume is always very loud. Has anyone else seen this? Is
>there some other tool which will actually control the volume?
the mixer is (currently) disabled on the 9652-hdsp. i have asked RME
to send me the commands
> I notice I get a message "IO box is a DigiFace" in dmesg. Is the
>mixer in DigiFace working, or is there some possibility that there's a
>clue there?
the mixer is disabled by the firmware on the 9652 because the
registers used to access it are different than on the hdsp. so yes,
the hdsp mixer
>Latency: 4096 samples (2 periods of 16384 bytes)
>Hardware pointer (frames): 0
>Passthru: no
>Clock mode: autosync
>Pref. sync source: ADAT1
>
>IEC958 input: Coaxial
>IEC958 output: Coaxial only
>IEC958 quality: Consumer
>IEC958 emphasis: off
>IEC958 Dolby: off
>IEC958 sample rate: error flag set
>Martin,
> That might certainly be an answer. How would this amixer switch get
>st in the first place? I wouldn't mind doing it by hand once as long as
>it was then loaded after that.
what you want is a short startup script (typically in somewhere under
/etc/rc.d, but unfortunately this varies s
>the standard alsasound init script can call a card-dependent script
that reminds me. the last version of the alsasound script that i saw
did something very dangerous. it seemed to try to install *every*
snd-card module it could find. if you have a system with an ISA bus,
this can prove fatal to t
>IMHO this is a design bug of all rme cards. The documents about rme32 and
>rme96 where identical in this point. They were talking about one master-mode
>and nothing about the frequency. I don't know anything about rme9652 or
>hdsp, but the sourcecode looks not very different to the older rme96.
>
>> that reminds me. the last version of the alsasound script that i saw
>> did something very dangerous. it seemed to try to install *every*
>> snd-card module it could find. if you have a system with an ISA bus,
>> this can prove fatal to the system - many ISA device probes will kill
>> the machin
>yes, thnx, it's much clearer now. my converter is external with no
>rate switches and from the manual i just discovered it always
>operates at 48000 (Alesis AI-3). i'm s till uncertain how to change
>the card's configuration though. "alsactl" doesn't se em to provide
>an obvious way to do this
>I wonder if this could have anything to do with a different problem I'm
>seeing. I have a HDSP 9652 and a MidiMan 2X2 interface. The HDSP is
>installed by alsaconf. The 2X2 is installed usign Fernando's
>instructions from the Planet.
>
>When I do a cold boot, the HDSP is always recognized first, a
>by hand, changing the 'Sync Mode' value from AutoSync to Master
>(should these values be in quotes?), ran "alsactl store hammerfall",
>unloaded then reloaded the alsa m odules, then ran "alsactl restore
>hammerfall. ("hammerfall" is the card's id.) but asound .state
>still indicates Sync Mode is
>it works! disks burn correctly now. thanks to everyone who helped
>me get thi s straightened out, especially paul davis and joerg
>shilling. in case it might help someone else, i'm running a redhat
>based system and load the hammerfall modules at boo t time with this
>lin
>
>This part of PCM API has not been discussed. I think that we should follow
>the most easy way: It is - allow only sample rate given by application, if
>the master clock is using another sample rate - in trigger() callback -
>driver will fail.
this seems wrong to me. what should fail is an atte
>In the interest of correct documentation how is this explained:
>
>hw:0,0
>
>The first zero is the card number?
>The second zero is the device number?
the first index is the card number, the second is the device and the
third (rarely used) is the subdevice.
>What happens for sound devices that a
>> this seems wrong to me. what should fail is an attempt to set the
>> sample rate unless the hardware is its own clock Master. if no attempt
>> is made to set it, then the application gets whatever the hardware is
>> running at, whether that is externally controlled or some h/w specific
>> defaul
--- Forwarded Message
Date:Sun, 05 Jan 2003 16:31:00 +0100
From:Jan Lindemann <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: patch: module dependencies for Hammerfall DSP
- --Boundary-00=_O3Z8X6R9W6E459ZQIQUK
Content-Type: text/plain;
charset="us-ascii"
Conten
>Let's suppose this playing is going on and a new fresh input arrives on my
>input channel. So I would think the hardware will run in master mode and the
>software will say: slave mode. I'm really not happy about this solution. I
>would prefer a solution with precise modes or error messages if neca
>That is, of course, not an acceptable solution, and it also doesn't
>work when you're using the ALSA sequencer interface (at least from the
>API calls I've seen). Fixing it in the driver requires interpreting
>much MIDI, possibly buffering, and has some problems (what if someone
>writes an incomp
>> i'm afraid its an entirely acceptable solution, and its the same one
>> required by many other non-audio, non-MIDI device types. if you have
>> multiple threads writing to a disk-file, for example, and they
>> interleave their calls to write(2), you will get mixed up data on
>> disk.
>
>Actually
>That's what drivers are for. ;) The ALSA sequencer shouldn't have to
>know of course, but the driver should be able to handle it, and the
>architecture should allow a working driver.
i'd agree with that.
>> another example of this that i know a bit more about is on the
>> tropez+. this has two
>Mark Knecht wrote:
>>I recently purchased an RME HDSP 9652 card. The card is working fine
>> for audio, but the MIDI interface is a timing disaster. The interface
>> works, but won't keep time. A 2 minute song is Rosegarden takes abut
>> 2:45 to play every time. You can hear how the HDSP isn't
Index: hdsp.c
===
RCS file: /cvsroot/alsa/alsa-kernel/pci/rme9652/hdsp.c,v
retrieving revision 1.16
diff -u -u -r1.16 hdsp.c
--- hdsp.c 7 Jan 2003 10:36:32 - 1.16
+++ hdsp.c 13 Jan 2003 13:32:32 -
@@ -817,10 +81
[ cc'ed to alsa-devel ]
>I think I've asked something to this effect before, but is there any
>reason why the polling portion of alsa_driver_wait should not be in
>libasound? It's a very complicated piece of code that performs an
>operation that many programs are likely to want. What if it was
>> that said, i think it would be great if this found its way into libasound.
>
>I wonder why to implement this function when one can link more pcm streams
>with "snd_pcm_link()" together? Then polling one stream is sufficient when
>streams are hardware synchronized.
why don't you go read the func
>> that said, i think it would be great if this found its way into libasound.
>
>is the below code ok?
>
>int snd_pcm_wait_many(snd_pcm_t **handles, int num_handles, int timeout)
>{
> struct pollfd *pfds;
> int i, err;
> pfds = (struct pollfd *)alloca(sizeof(*pfds) * num_handles);
>> seems like a good idea to me, although there is a small problem. the
>> current snd_pcm_wait function waits till the handles is
>> readable/writable, whereas the JACK code waits till the handles all
>> have a certain minimum amount of data/space.
>
>It does? Reading the function, I cannot find
>So resume:
>
>1) use snd_pcm_link to link all streams
we already have hardware that doesn't support linkage between
playback+capture.
>2) start first linked stream (thus all in paralel or serial or combination
> sequence)
>3) poll the last stream handle for valid position
>
>And you don't ne
if you try to play a 22.05kHz stream on hardware that supports 32kHz
and 44.1kHz but not 22.05kHz, alsa-lib's plughw layer chooses to use
32kHz and resamples. this seems like an error to me: it would be much
better to choose 44.1kHz and do simple integer resampling. that is:
the search for the best
>This would explain why snd_hdsp works (i.e. you can playback and
>record through the default I/O), although amixer doesn't do anything:
>the driver doesn't have to set up any default connections, because
>those are part of the FPGA reset state. I would be surprised if
actually, the driver does h
>Yes, I understand that that's what the driver is _supposed_ to do.
>That's how it works on my HDSP PCI and Cardbus systems. But isn't it
>true that the current driver doesn't actually set up any of those
>zero-gain connections for the HDSP 9652?
well, it attempts to, but its writing to the wrong
>I've been messing with hdsp and found out an interesting issue. After
>installing the driver for the first time onto the xp machine I also had
>no sound coming out of the soundcard even though totalmix app showed
>levels to be up. After clicking on the levels and/or moving them a bit,
>suddenly th
>I would like to fully understand the exact meaning of buffer_size and
>period_size and how can I compute the final latency in the full duplex
>processing from these variables.
period_size = frames between interrupts from the hardware
buffer size = total frames for the hardware buffer
max output
>Paul,
> So with -p 64 -n 2 settings, what number of bytes of audio data is
>transferred across the PCI bus between each interrupt?
the period size is always (as with almost all ALSA metrics) in units
of audio frames (1 sample for each channel). so with JACK running at
-p 64, 64 frames of data a
>I am asking this, as the ALSA OSS compat. seems to be getting depreaciated (I
>dont blame it), and stuck on rc1.
its not deprecated, though many of us would actively discourage anyone
from writing new applications that use the OSS API. its very important
for ALSA that it fully and properly suppo
>And instead of bothering people with silly questions, 'how do I perform x OSS
>function", I went looking at the docs. The tutroials are very good, but don't
>touch upon some of the more compilcated aspects. It seems maybe there is a
>glossary or something needed for people more familiar with OS
>1) does alsa have support for multichannel output? If so, how would one go
of course.
>about sending individual signals to channels 1-8?
depends on the access format: interleaved or non-interleaved. it also
depends on whether you are using read/write access or mmap-based
access.
so you have
i don't know how we ended up with such incorrect values for the
period/buffer size limits, but this corrects them. this previously
prevented applications from requesting a period size of 8192
frames. an identical patch is needed for the hdsp driver. i'll post
one tomorrow if jaroslav or takashi don
>> To be explicit: whenever you see a bug, don't just
>> ask how to fix this instance of the bug; ask what
>> it would take to make sure no bug of this ilk ever
>> occurs again.
>>
>> In this case:
>> a) It would help to have some comments in the code
>> saying where the constants are coming f
>Is it possible to have both stream pointers working on the same physical
>buffer? A slightly delayed start of playback should then give a nice IO
>latency. Are there any other approaches viable? Ideally i'd like to get this
>working while not depending on userspace scheduling heavily.
you have
>Speaking as a userspace developer, I expect file
>descriptors to be inherited by child processes unless
>I explicitly request otherwise. Yes, I usually make
>sure that I *DO* request otherwise, but that's not the
>point...
the question is not about inheritance by child processes. its about
close-
>The API does not *need* to set the FD_CLOEXEC flag,
>and so it should not. It is the height of arrogance to
>assume that something has no use simply because you
>can't imagine using it.
there's a little detail you're forgetting. unless the hw supports
multi-open and the current number of subunits
>> there's a little detail you're forgetting. unless
>> the hw supports multi-open and the current number of
>> subunits is below the limit of the number of opens,
>> then having the descriptor will cause all other
>> attempts to access the device to block (unless they
>> explicitly request non-blo
501 - 600 of 798 matches
Mail list logo
