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* done in
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 done in
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
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
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 connectors
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, using
the hw params include information on both the sample bit width and
`mostsignificantbits', 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
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
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 who
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
32 on the
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,
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.
i hope
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
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' module
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(dd-pcm,
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,
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 to
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 control
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
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
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
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
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
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.
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
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
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:65
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 revents set
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
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
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
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
background: afaik, with the ice1712 for example it is possible to
run two or more cards in sync. will this be as simple as calling
snd_pcm_open for n streams, and snd_pcm_link (stream[0]) for
streams [1, n - 1]?
no, i don't think that's the plan. you use the multi PCM device type
in an
In message [EMAIL PROTECTED]you write:
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't i share the
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).
My interpretation: two cards will drift. or something. can you be more
clear about what you mean? they will drift if you do use the same
In message [EMAIL PROTECTED]you write:
Andy Wingo wrote:
hw:N,M: the Nth card, with the Mth pcm device. N and M start with 0.
this device does not use the software plugin layer.
hwplug:2,0 was the setting was the one I was looking for. Dunno what it
means, but seems to work. hw:2,0 didn't
it's been the same with MOTU, some vendors are just ignorant of a
large potential customer base.
lets not kid ourselves. there is a *tiny* potential customer base for
the next several years at least, and the existing customer base is
even smaller.
the customer base for audio chipsets in things
i seriously doubt that. perhaps it's true for additional companies, as
hammerfall is well established in the high-end and m-audio (and terratec)
how many hammerfall purchasers do you think run linux? even the fact
that the most impressive and forward-thinking demo of the last 2 years
(mcgill's
If hardware manufactures wanted their products to have good support on
Linux, all they have to do is publish the hardware programming details, and
the linux community will do the actual driver development.
thats why i wrote inertia-bound companies. they don't see this. they
think that linux
Linux runs on at least a dozen h/w platforms. AFAIK, no device driver
directly includes assembler, and if they do, they are unlikely to be
part of the mainstream kernel. They certainly wouldn't be part of
ALSA, I would hope.
a part of assembly-howto :)
[ ... example elided ... ]
Small,
In message [EMAIL PROTECTED]you write:
Hi. I'm writing the alsa plugin for gstreamer. When I go to capture audio, my
loop eats the entire cpu. I set avail_min but still sometimes get out 32 frame
avail values. Here's the relevant portion:
/* shamelessly stolen from pbd's audioengine. thanks,
there are two of these loops running separately, one for each
element, with separate handles, etc. I was thinking for some reason
that snd_pcm_update_avai l would block until avail_min frames were
available, but that's not the case. If I run the following pipeline,
I get:
snd_pcm_avail_update():
I just came to a pseudo-epiphany, but I can't test it atm. Do I poll
on the fd , but set pfd.events = POLLIN | POLLERR?
there now, that wasn't too hard, was it? :))
the rest of the code should look identical.
note that audioengine (and now JACK) is technically in error because
it only polls
Don't laugh. This is from a review of the Creamware Luna II card, from
Remix magazine:
--
With some direction from CreamWare's technical support staff, I found
that Fruityloops works best with DirectSound drivers, whereas Acid
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.
where does this rule come from? i was under the impression that
poll(2) should timeout in those cases, not
From the RME documentation it appears that it is possible to detect when a
source is connected to the RME 9652 card, and whether the source has the
sampling rate expected. But when I try to read from the card using ALSA, I
get data whether or not the card has any input. Is there a way to detect
well, jaroslav's patch (to change the ESO value) was most of the
solution. in the diff below, i have also cleaned up the spurious
interrupt detection. with these two changes, i can run my trident with
a configuration that previously caused endless xruns in full duplex
mode (44.1kHz, 64 frame
Your patch doesn't take care about frequencies other than 48000Hz, because
stimer is absolute 48000Hz timer, so the spurious threshold should be
adjusted for other sample rates as well. I've put your code with my
modifications to the CVS tree.
my attempt was to make it independent of srate by
in doing lots of testing on JACK, i've noticed that although the
trident driver now works (there were some patches from jaroslav and
myself), in general i still get xruns with the lowest possible latency
setting for that card (1.3msec per interrupt, 2.6msec buffer). with
the same settings on my
In message [EMAIL PROTECTED]you write:
anyone know why when viewing a flash plugin in netscape with audio and
alsa the sound is super-choppy? i don't get this problem with oss. using
ice1712 and alsa-cvs-10/20/01.
i'm using a much older version of ALSA with the trident and viewing
madblast.com
What is a difference between an ASCII identifier plughw:0,0
and hw:0,0? And what the output of 'aplay -L' means?
a hw device is totally constrained by the hardware characteristics
of the underlying audio interface. if the device has 26 channels, then
it must be used with 26 channels; if it only
i'm pleased to announce that, with the continuing collaboration of
RME, work on the driver for the RME Hammerfall DSP will be beginning
soon after the start of 2002.
--p
___
Alsa-devel mailing list
[EMAIL PROTECTED]
I think that it's nonsense to force average users to study the
alsa driver architecture and learn a format of the configuration
file (they just don't know about the existence of such file) to
average users have 1 sound card. default will work for them.
perform such trivial task as to point the
ok, suppose i merge two PCM devices into one multi device. then
suppose i do the same for the corresponding control device.
how does an application access the control switches for the multi
device? in the underlying hw devices, there are duplicate sets of
control switch names. how can i refer to
1) Is it necessary to open the device twice, as opposed to opening
it once, passing SND_PCM_STREAM_PLAYBACK|SND_PCM_STREAM_CAPTURE instead?
yes it is. ALSA PCM streams are uni-directional, always. we've played
with it the other way, and there were some problems.
2) Doesn't the link function do
Is there any real time application or applications, that have been made
directly to ALSA?
please be a bit more descriptive when you use the term real time. it
has many different meanings, and so its impossible to answer your
question clearly without more definitions of what you mean.
--p
Paul, could you spare some more keystrokes on what you
think are the best steps to take to solve this problem ?
actually, i don't see a way forward.
neither jaroslav nor abramo have indicated that they accept the
desirability of imposing a synchronously executed API (SE-API; this
being the
Most sound apps have to turn the PCM into the frequency domain before
applying a sound effect anyway, why not just stay in the frequency domain.
this is not true. most audio FX are carried out in the time domain. i
don't know many sound apps that do what you describe unless they are
doing
I'm ommiting discussion about questionable efficiency of a callback based
API in unix environment here.
abramo and i have already disagreed, then measured, then agreed that:
although an IPC-based callback system is not ideal, on today's
processors, it is fast enough to be useful. the gains this
I don't think this is relevant wrt Jaroslav objection. He was not
proposing a *all-in-a-process* solution.
i don't see what other issue surrounds questionable efficiency of a
callback based API in unix environment. can you enlighten me? i also
note that CoreAudio runs in a Unix environment
I meant mainly streaming applications for full duplex usage.
ecasound and ardour both do this, and JACK provides an API for
applications that do this. i think GLAME might do this to, though i am
not certain of its full duplex-ness.
i am the author of ardour and the primary author of JACK. if
1/ the ability to do the cleanup (nothing more is needed)
2/ reliability and fidelity to the original
3/ ease of use (i don't mind command line, but won't be able to figure out
too tech savvy parameters)
check dave phillips sound+MIDI pages for linux. there are at least 2
or 3 denoising
[snip]
what you're missing is that high end applications need *two* things:
1) low latency
2) synchronous execution
the latter is extremely important so that different elements in a
system do not drift in and out of sync with each other at any time.
If it is possible to have an
I have looked at the Jack web page (http://jackit.sourceforge.net/)
It would help more if jack.h had more documentation for all api function,
and not just a few of them.
well, we're not quite finished with the API yet. Once its really set
in stone (for v1.0), something that i imagine will
Here there is no requirement for low latency or synchronous execution.
The requirement is just that the app is told exactly how long it will be
between the next samples written to the driver, and
the sound actually coming out of the speakers.
there's another very important i forgot here. because
I'm not sure if I understand why this would help to position jack as the
standard linux sound server. It seems like we need to get some kind of
discussion going between arts and jack developers as arts is in the position
that jack would like to share. No doubt that jack has something to offer
API which pretends to be one and only for linux must work not only with
JACK is not an API pretending to be the one and only anything. Its an
API designed to fill a niche that nothing else is doing for Linux. It
has been written with 98% of the attention paid to high end apps. If
it happens to
Paul,
As you obviously know more about Jack than I do, can you explain how an API
like Jack could provide information to the APP so that Audio and Video can
be kept in sync.
JACK doesn't do that. JACK is run by a single timing source (called a
driver). that timing source can come from anything -
On Tue, Jan 15, 2002 at 08:06:43 -0500, Wm. Josiah Erikson wrote:
Shucks. I was afraid of that. I'll bug them some more, and if I get really
ambitious (I know nothing about it), perhaps try and reverse engineer
something. Is this technically possible?
On another note, are there multitrack
jaroslav -
for some time now, i've had a version of the wavefront driver that
doesn't require any module parameters - it just uses isapnp to figure
out the configuration of the card. i would have submitted the changes
to you already, except for one problem. after a reboot (cold or warm),
the
But it does register itself to the OSS subsystem (to
drivers/sound/sound_core.c) like all other sound drivers, so it _is_
part of OSS.
no. sound_core is NOT part of OSS. ALSA attaches to it as well. Alan
Cox wrote that so that OSS and ALSA could (theoretically) co-exist.
Now I'm
NO one has specifically sent a copy of the file for the Delta 66 that I
can seem to understand and there seem to be a few diferent versions
floating about on the mailing lists. (ardour-dev,alsa-dev, and
alsa-user).
If anyone could help here by sending an asoundrc file configured for a
similar
Hello problem like that:
I got ardour workin with my motherboard via686a driver card but it
hanged bad in some fase of using ardour.(no use anyway for that noisy
card)
I got Xwave 6000 Pro too but here comes up some errors.
I use 0.9.0beta10 drivers and libs 2.4.8 kernel mdk 8.1.
what's this?
So, how do we ever get anyone who makes money to recognize that
everything in this description is true of Linux/ALSA as well?
(Rhetorical question, I think).
--p
--
Propellerhead Software, the Swedish company behind acclaimed
I am offering my machine and some of my time for finding
and fixing issues with the via686a. AMD 1Ghz, Kernel 2.4.14+
do you know about the athlon paging h/w bug?
--p
___
Alsa-devel mailing list
[EMAIL PROTECTED]
why would snd_pcm_mmap_commit() take an amount of time to execute
that is linear with the number of frames committed (on h/w that
supports mmap mode without any games) ?
with 64 frames, and a hammerfall, it takes 36 usecs; with 4096 it
takes 2.3msecs. the code doesn't suggest anything to me ...
Paul Davis wrote:
why would snd_pcm_mmap_commit() take an amount of time to execute
that is linear with the number of frames committed (on h/w that
supports mmap mode without any games) ?
with 64 frames, and a hammerfall, it takes 36 usecs; with 4096 it
takes 2.3msecs. the code doesn't
Hello all,
it seems that I've finished an initial version of documentation
for alsa-lib's configuration files and PCM interface. Here is URL:
looks like a decent start. i hope i can find time to improve some
parts of this. in reading the section on the syntax of config files,
however, i
Are you serious about xml? Do you have smoked something weird?
xml was just an example. i happen to like it, because there are
standard parsers, and standard presentation tools. but i wasn't
seriously suggesting it as an alternative. i would just feel more
comfortable with a language that wasn't
Jeremy has correctly answered many of the points/questions you
raise. I will try to finish off the story :)
problem is that I cannot get the mixer to have any elements (or
elems as the alsamixer calls them) which thus makes the card
un-openable even with the alsamixer.
there is no mixer.
just writing a recording app with alsa lib i found i need
to use
snd_pcm_start(chandle);
Why? What does it do?
the hardware of audio interfaces doesn't activate all by itself - it
needs to be told to start processing i/o and generating interrupts.
when you open a handle on either the
1) I understand now that there is no mixer. Yet, I am a bit baffled how then d
oes ardour (for instance) control this app's output? Couldn't there be a some
kind of generic mixer app derrived from the way Ardour addresses volume issue
in this card? Could it be that the app only attenuates the
1) I understand now that there is no mixer. Yet, I am a bit baffled
how then d oes ardour (for instance) control this app's output?
Couldn't there be a some kind of generic mixer app derrived from
the way Ardour addresses volume issue in this card? Could it be
that the app only attenuates
Also, could someone please be so kind to send me their asoundrc file
that they are using for the hammerfall, so that I can learn from it as
to how to configure it since the one that comes with alsa-driver package
is rather esotheric for my understanding? Thank you very much!
this is mine.
Hello
I am thinking of writing a low level sound card driver for alsa.
The card in question is the dxr3 hardware DVD player, which has analogue and
SPDIF out.
It currently works fine with OSS drivers.
The card has no mixers, or recording function, just write and GETOPTR,
SETSPEED etc function in
It seems I have been celebrating too early.
Here's the scoop on my current issues:
I have finally managed to produce sound with the darn thing, but every
so often now I get sporadic crackle out of the output, as well as
complete distortion of the sound, almost as if the pitch is constantly
i have had this problem from time to time as well. i am still, after 2
years of working with the hammerfall, unsure of what causes it.
Could it be a PCI problem? Latency timer issue? Busmastering problem?
it seems to be related to the condition of the h/w when it was stopped
and/or restarted,
Well, I tried restarting the alsasound and that did not fix it at all.
Granted, I was also trying to use cmixplay command which most likely
invokes rme card via oss emulation, and I've heard that oss emulation is
a bit flaky. So, I did end up having to restart the machine to get the
sound back in
the hammerfall cannot do this. the hammerfall-DSP can do matrix
routing of signals between channels, but it does not mix software
streams down to a channel.
Crap! :-) So does this mean that RME card cannot be accessed from
multiple applications at the same time? This is one of the most
I have seen that alsa provides nice pcm devices in /dev/snd directory
*They are split in playback and capture devices :) nice idea.
In Oss I was able to pipe data from and to them and therfore was
recording/playing back at a certain sample rate.
With alsa this is not possible anymore. it says
Anyway, I believe going with the sequencer is the better solution anyway;
IMHO, its not. i had to do this to download a huge firmware update via
sysex to our Alesis M20 ADAT's last year, and ran into all kinds of
problems. Unless your Sysex messages are all rather short, the
sequencer is not
should it work for me to call snd_pcm_drop() for both playback and
capture streams if i'm in the middle of a snd_pcm_mmap_{begin,commit}
pair?
unless i use RT timing, on both the trident and hammerfall, doing do
invariably causes an effect upon restarting the streams that suggests
an out-of-sync
should it work for me to call snd_pcm_drop() for both playback and
capture streams if i'm in the middle of a snd_pcm_mmap_{begin,commit}
pair?
Nope. Do you think that we need to lock these related code blocks in
alsa-lib for threaded applications or leave this locking for application
coders?
poll
snd_pcm_mmap_begin();
snd_pcm_mmap_commit();
poll
snd_pcm_mmap_begin();
... realize things have gone wrong ...
snd_pcm_drop();
snd_pcm_prepare();
snd_pcm_start ();
poll
snd_pcm_mmap_begin();
snd_pcm_mmap_commit();
i would have
1 - 100 of 578 matches
Mail list logo
