On Oct 18 Ricardo Colon wrote:
I'm trying to implement a library to run on top of ALSA which is only
designed to support one-way devices... a duplex device would be treated
as separate input and output devices, like in Windows, and it seems like
there aren't any elegant ways to do it.
you keep
from the driver source, it would appear an issue with whether the card
is using 16 or 8 bit DMA. if its using 8 bit DMA, you don't get
S16_LE, which is one of the two formats Ardour can use (S32_LE being
the other)
it appears that there is a control for the card that sets the DMA
mode; alsactl
Today Jaroslav Kysela wrote:
On Tue, 23 Oct 2001, Tim Goetze wrote:
state.awe64 {
control.1 {
comment.access 'read write'
comment.type ENUMERATED
comment.item.0 Auto
comment.item.1 Playback
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
Today Abramo Bagnara wrote:
Paul Davis wrote:
avail = snd_pcm_avail_update(pcm);
while (avail 0) {
frames = min(avail, block_size);
snd_pcm_mmap_begin(pcm, areas, offset, frames);
process(frames);
Today Manush Dodunekov wrote:
On Thu, 1 Nov 2001, stef wrote:
[EMAIL PROTECTED] wrote:
I have an emagic AMT 8 midi patch bay. (Similar to Unitor 8).
I have this one, too. Works great with our apple macintosh.
1) Is anyone working on a driver for this?
Don't know. But it would be
Today Jaroslav Kysela wrote:
On Mon, 12 Nov 2001, Tim Goetze wrote:
it appears alsa/asoundlib.h is missing some declarations and
definitions related to snd_ctl_power_* in current alsa-cvs.
alsa-util/alsactl will not compile. i locally patched asoundlib.h to
provide these declarations
Today Abramo Bagnara wrote:
Paul Davis 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).
My interpretation: two cards will drift. or something. can you be more
clear about
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.
ok. here's a rule simple enough for me to remember :) but should poll in
this case,
On Dec 1 Abramo Bagnara wrote:
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.
ok. here's a rule simple
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
happen).
This is the rule you need to remember.
where does this rule come from? i was under the
i'm doing full-duplex mmapped io on emu8k. the good news is the streams
stay in sync, the bad news is how the processing occurs is not optimal if
one follows the 'schoolbook approach'.
remember the alsa schoolbook:
while (running)
{
poll();
available = min (streams-update_available());
the doc to snd_pcm_mmap_commit says
* \return 0 on success otherwise a negative error code
but on success it rather seems to return = 0 (the number of frames
commited i think).
please clarify and fix.
tim
___
Alsa-devel mailing list
[EMAIL
Jaroslav Kysela wrote:
Hello all,
I need your advice here. The current snd_pcm_mmap_commit()
function returns zero or an error. I've added a new function
snd_pcm_mmap_commit_partial() to detect partial transfers as well:
int snd_pcm_mmap_commit(snd_pcm_t *pcm,
Abramo Bagnara wrote:
Tim Goetze wrote:
Jaroslav Kysela wrote:
Hello all,
I need your advice here. The current snd_pcm_mmap_commit()
function returns zero or an error. I've added a new function
snd_pcm_mmap_commit_partial() to detect partial transfers as well:
int
Abramo Bagnara wrote:
Tim Goetze wrote:
but sometimes i also get inexplicable corruption within ordinary
dynamically allocated memory of the process before it exits.
i have spent considerable time on verifying that these are indeed
caused by changing the period_size, and not by my own
Charles Flèche wrote:
Thanx a lot for your help ! I'm working on this project for my
university, and if this soft don't work, I'm going to do another
year... HHAARRRGGG !
although this is probably not the preferred way (by the ALSA team) of
using the interfaces, you can access MIDI
Gerald Grabner wrote:
Hi,
I'm just starting to write my first alsa-lib midi applications. I'm
wondering what the acronym ppq stands for and what it means (especially
in relation to tempo). Unfortunately, I didn't find any docu on the
topic of tempo.
from sound/asequencer.h:
/* queue tempo
Paul Davis wrote:
I'm just starting to write my first alsa-lib midi applications. I'm
wondering what the acronym ppq stands for and what it means (especially
in relation to tempo). Unfortunately, I didn't find any docu on the
topic of tempo.
int ppq; /* time resolution, ticks/quarter
hi all,
both emu8k and ice1712 pcm drivers hang forever in ioctl(2) when
closing a playback stream if the stream has been linked to the
same card's capture, has been prepared and written data to, but was
never started:
Program received signal SIGINT, Interrupt.
0x403b8fa4 in ioctl () from
Takashi Iwai wrote:
At Thu, 30 May 2002 17:14:03 +0200 (CEST),
Tim Goetze wrote:
hi all,
both emu8k and ice1712 pcm drivers hang forever in ioctl(2) when
closing a playback stream if the stream has been linked to the
same card's capture, has been prepared and written data
me wrote:
me wrote:
Takashi Iwai wrote:
At Thu, 30 May 2002 17:14:03 +0200 (CEST),
Tim Goetze wrote:
hi all,
both emu8k and ice1712 pcm drivers hang forever in ioctl(2) when
closing a playback stream if the stream has been linked to the
same card's capture, has been prepared
me wrote:
me wrote:
me wrote:
Takashi Iwai wrote:
At Thu, 30 May 2002 17:14:03 +0200 (CEST),
Tim Goetze wrote:
hi all,
both emu8k and ice1712 pcm drivers hang forever in ioctl(2) when
closing a playback stream if the stream has been linked to the
same card's capture, has been
me wrote:
strange, this has to be fixed already.
and the filename in the patch you attached seems invalid.
could you check whether all the sources are updated?
the latest versions are:
alsa-kernel/core/pcm.c rcs rev. 1.12
alsa-kernel/core/pcm_nativ.crcs rev. 1.13
) 2002 Tim Goetze [EMAIL PROTECTED]
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version
Philipp Vollmer wrote:
it seems params == 0 when you're calling snd_pcm_hw_refine.
Hello,
Sorry but there is no codeline like snd_pcm_hw_refine in the example.
I will send you the file as an attachment.
in your file:
if ((playback_handle = snd_pcm_open (playback_handle, default,
Anders Torger wrote:
On Saturday 27 July 2002 17.18, you wrote:
Anders Torger wrote:
Does anyone have any comments on this? Is repeatable exact I/O-delay
possible to achieve today with current hardware (and ALSA)?
It is the normal mode of operation for memory-mapped IO.
Is it really? How
Is it possible to register a sequencer client that acts as a timer
(not only an event consumer/producer), and if so, how would one go
about implementing one?
tia,
tim
---
This sf.net email is sponsored by: OSDN - Tired of that same old
Takashi Iwai wrote:
At Mon, 19 Aug 2002 17:42:07 +0200 (CEST),
Tim Goetze wrote:
Takashi Iwai wrote:
At Mon, 19 Aug 2002 09:22:10 +0200 (CEST),
Tim Goetze wrote:
Is it possible to register a sequencer client that acts as a timer
(not only an event consumer/producer), and if so, how
Takashi Iwai wrote:
How can we implement the latency-optimal behaviour with alsa-driver
framework?
Can we implement something like a snd_1ms_elapsed() routine (called from
USB-interrupt), which in turn triggers a waiting app with the available
period size (which would be 44 or 45 frames for
Takashi Iwai wrote:
With the current setup and cycle code for mmap'd IO (like Jack for
example does it), is it possible to use these devices at all?
on 48kHz my usb speaker worked fine with 1ms or 2ms period size (not
under high loads, though), since the frames per urb becomes integer in
this
Takashi Iwai wrote:
At Tue, 20 Aug 2002 13:34:03 +0200 (CEST),
Tim Goetze wrote:
Takashi Iwai wrote:
With the current setup and cycle code for mmap'd IO (like Jack for
example does it), is it possible to use these devices at all?
on 48kHz my usb speaker worked fine with 1ms or 2ms
Welkom terug, Frank!
I see 2 options for it (please correct me if I'm wrong since i've been away
for too long):
- sync the timer using SND_SEQ_EVENT_SETPOS_TIME events (and optionally
SND_SEQ_EVENT_QUEUE_SKEW). ALSA remains running it's own clock (system
clock, rtc, external clock),
Takashi Iwai wrote:
At Thu, 05 Sep 2002 01:35:39 +0900,
Patrick Shirkey wrote:
Sorry if this is stupid, I'm not a trained programmer. I get this now.
Do you know how to fix it?
% gcc -l qinit qinit.c -lasound -ldl -lm
rather
$ gcc -o qinit qinit.c -lasound -ldl -lm
^
i
Anders Torger wrote:
On Wednesday 11 September 2002 20.48, you wrote:
On Wed, 11 Sep 2002, Anders Torger wrote:
I use a RME9652 hammerfall with two periods (the hardware is that
way).
I watch a file descriptor associated to the output with select(),
when it gets ready for writing, I
Anders Torger wrote:
On Wednesday 11 September 2002 23.52, you wrote:
Anders Torger wrote:
[...]
The problem here is that the output buffer is full, the pcm is not
RUNNING, but the file descriptor gets triggered anyway. When can
that happen?
we had a hauntingly similar discussion about
Takashi Iwai wrote:
btw, the attached patch is a quick and untested hack to change the
behavior as you wish :)
please give a try.
i've already worked around it, but i think we save future coders
some work if we get this done right.
anyways, your patch doesn't break jackd (ice) and my
Takashi Iwai wrote:
if it's on the blocking mode, the driver should block if it's possible
to do write in future _by any chance_.
if it's not on the blocking mode, the driver should return -EAGAIN.
and, the behavior of poll() depends on the behavior of write().
if it blocks, then poll blocks,
Takashi Iwai wrote:
At Fri, 13 Sep 2002 11:36:54 +0200 (CEST),
Jaroslav wrote:
On Thu, 12 Sep 2002, George Philip wrote:
We are a group of four final year computer
engineering students intrested in your project.We saw that
you need free devolopers for your project.We would
Florian Bomers wrote:
Why does this happen ? I searched the mailing list archive and only found an
explanation that symbols don't match and I need to recompile the ALSA lib. In my
case it's a clean install of ALSA on a newly installed red hat system. There was
never any other version of ALSA.
Abramo Bagnara wrote:
let's imagine:
* a single-threaded app. if the coder omits starting the stream before
poll, he'll quickly find out that nothing is played/recorded, and that
poll will hit the timeout, and consequently revise his code logic.
It would be definitely not easy for the
Florian Bomers wrote:
On the practical side - how can I solve the problem ? I can't change the way my
plugin is linked to the main app, so do I need to manually dlopen() libasound
myself with the RTLD_GLOBAL flag (and not use -lasound ??)
until your copy of alsa has jaroslav's recent addition,
Jaroslav Kysela wrote:
autoconfiguration code to alsa.m4. My suggestion is to use /opt/alsa/rc3
directory for this job. Comments?
/opt is redhat only, debian systems do not have it.
tim
---
This SF.NET email is sponsored by: AMD - Your
Thierry Vignaud wrote:
Tim Goetze [EMAIL PROTECTED] writes:
autoconfiguration code to alsa.m4. My suggestion is to use
/opt/alsa/rc3 directory for this job. Comments?
/opt is redhat only, debian systems do not have it.
err, even if i dislike it, /opt is defined by the fhs
anyway, api
Takashi Iwai wrote:
since the old ice1712.c is still compiled as default, you'll have to
run make on alsa-driver/pci/ice1712. the new files are not compiled
otherwise.
[~/audio/alsa-cvs/alsa-driver] make -C pci/ice1712
make: Entering directory
`/home/tim/audio/alsa-cvs/alsa-driver/pci/ice1712'
Takashi Iwai wrote:
At Thu, 19 Sep 2002 16:35:19 +0200 (CEST),
Tim Goetze wrote:
[ak4524_t undefined ...]
make: *** [ews.o] Error 1
make: Leaving directory
`/home/tim/audio/alsa-cvs/alsa-driver/pci/ice1712'
could you check whether ice1712.h exists on alsa-kernel/pci/ice1712?
also, please
Takashi Iwai wrote:
At Thu, 19 Sep 2002 17:06:08 +0200 (CEST),
Tim Goetze wrote:
much simpler. you did a c++ style auto variable allocation, declare
'ak' at the start of snd_ice1712_ews_init and it compiles cleanly.
oops, never noticed that. i relied too much upon the compiler.
well
Takashi Iwai wrote:
At Thu, 19 Sep 2002 16:50:13 +0200 (CEST),
Tim Goetze wrote:
Takashi Iwai wrote:
At Thu, 19 Sep 2002 16:35:19 +0200 (CEST),
Tim Goetze wrote:
[ak4524_t undefined ...]
make: *** [ews.o] Error 1
make: Leaving directory
`/home/tim/audio/alsa-cvs/alsa-driver/pci
Duncan Sands wrote:
(1) the hotplug subsytem is started. This automatically
loads the snd-usb-audio module and the modules it
depends on. In particular /proc/asound/ is created.
(2) the alsasound init script is run. It detects that
/proc/asound/ exists, and exits at once. In particular
it
Abramo Bagnara wrote:
Takashi Iwai wrote:
it CAN happen if you have multi-threads.
the problem is that we have no option to block the poll.
If you have multi-thread you have other alternative to do that.
OTOH application can't detect *why* poll is blocking with the change you
advocate.
as
it seems snd_pcm_hw_params_clear() is declared but never defined
in current cvs.
oss mixer and playback pcm work fine with the latest kernel modules
however.
tim
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
updated alsa-cvs this afternoon; alsactl produces an oops when
treating the ice1712 (audiophile). same for envy24control.
pcm seems to work fine (can't hear anything though).
dmesg | ksymoops attachment.
tim
ksymoops 2.4.5 on i586 2.4.19-ll. Options used
-V (default)
-k
me wrote:
updated alsa-cvs this afternoon; alsactl produces an oops when
treating the ice1712 (audiophile). same for envy24control.
attached patch fixes the problem.
tim
Index: alsa-kernel/pci/ice1712/ak4524.c
===
RCS file:
nick wrote:
is this because of the cards or my code?
it's the hardware -- all hw i know of is hard-wired for one
of the two access types. interleaved is much more common.
tim
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek
Brian Victor wrote:
On Thu, Jan 16, 2003 at 08:39:23AM +0100, Clemens Ladisch wrote:
Brian Victor wrote:
Monitoring /proc/asound/seq/queues shows the events being queued, but as
soon as the queue starts, all 400 notes leave the queue instantly; none
are played.
afaik, you should use
i have a new box with an ASRock K7VM2 board, it comes with an on-board
audio interface:
lspci -vv
00:11.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio
Controller (rev 50)
Subsystem: Unknown device 1849:3059
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV-
Takashi Iwai wrote:
modules.conf
options snd-via82xx index=0 id=ac97 ac97_clock=48000 dxs_support=2
/modules.conf
other dxs_support values cause block-size *and* erratic distortion in
the output sound. ac97_clock=44100 causes slowed-down playback.
ok, i'll add dxs_support=2 as default for
Friedrich Ewaldt wrote:
Is there anything else I could try? Any additional debugging information
I can provide besides the info in the 2 user-list mails mentioned above?
Thanks in advance for any help!
have you tried enabling the kernel build options 'IO-APIC support on
uniprocessors' and 'Local
Mark Knecht wrote:
Hi. Ok, since you suggested it I set up this Via 8235 sound chip on
my system as the primary sound chip. However, it's sounding amazingly
bad! It's terribly distorted and even at the best of times sounds very,
very,phasey. I can pretty much hear what sound like terrible
Clemens Ladisch wrote:
Denis de Leeuw Duarte wrote:
I'm starting work on a new midi sequencing app, but I'm a bit confused by
the different API options ALSA offers. I've been reading whatever snippets
I can find on the web, mostly mailing list archives, and if I understand
correctly my
Clemens Ladisch wrote:
Tim Goetze wrote:
* what kind(s) of sync-to-external will you need?
* do you want to receive/send MIDI sysex data?
last time i checked, the latter was impossible to do via the sequencer
API (please correct if things have changed).
Sending/receiving sysex has always
this thing caught my interest:
http://m-audio.com/index.php?do=products.mainID=2505615704f241ab716639de0db48fef
it's a control surface (faders, knobs etc) and seems to be able to
act as a MIDI I/O interface when connected via USB, which is the
only mode of operation i am interested in (out of
Frank Barknecht wrote:
Yeah, it looks like it is exactly the same, only a lot more expensive
than the real one, which is available below 200 Euro for example here:
http://www.netzmarkt.de/thomann/artikel-160144.html
Well, now I see that there is a difference between the uc33 and the
uc33e, at
Martin Langer wrote:
It looks like an evolution product:
http://www.evolution.co.uk/products/evo_uc33e.htm
The evolution keyboards in the past were using normal USB MIDI drivers. Good
chances that the uc33 is running in compliance with the specification, too.
But I can't give a promise here. In
when calling snd_pcm_unlink (stream) after an xrun occurred, it
returns EINVAL (hw: device, duplex, mmap'd IO, stop_threshold = ~0),
even though 'stream' is a valid PCM stream handle.
the snd_pcm_unlink code path seems to return EINVAL only if the stream
isn't linked to another.
but EINVAL
[EMAIL PROTECTED]
Hullo, I can't seem to find how to create MIDI channel mode messages
(like reset all controllers or all notes off), nor can I find out
how to create many MIDI meta events (like text event or copyright
notice or sequence name), I've been able to find out how to create
some events
[EMAIL PROTECTED]
I've been told that meta events can't be handled by the sequencer,
and thus midi doesn't have any mechanisms for creating them, apart
from setting the tempo(I can understand this, since the sequencer
doesn't care about lyrics or copyright). shouldn't the sequencer be
able to
[Remi Bernhard]
I read a lot a great thing about the audiophile 24/96 on the net, and i
decided to buy it to get better latency than my old sblive! I just
received the audiophile 24/96 and unfortunatly, i have a lot of XRuns
with when i run jackd.
my old system had various 2.4.x-ll kernels, asus
[Remi Bernhard]
So i have 2.6.5 kernel, and not 2.4.x. Do you think i should install
2.4.25 instead ?
i do think so because i never saw any hard facts about latency posted
for the 2.6 series, while 2.4.x-ll is well documented and proven to
work quite well here and elsewhere.
it _could_ also be
[Remi Bernhard]
To be more sharp, i need to reduce latency because i use softsynth
(zynaddsubfx, fluidsynth, etc.) that needs a low latency when playing
from midi keyboard, and if not, there is a lag time, that man can
hear, between the time when you hit the key, and the time it is played.
I
[Jan Depner]
On Sat, 2004-05-29 at 07:13, Tim Goetze wrote:
[Remi Bernhard]
To be more sharp, i need to reduce latency because i use softsynth
(zynaddsubfx, fluidsynth, etc.) that needs a low latency when playing
from midi keyboard, and if not, there is a lag time, that man can
hear, between
[Remi Bernhard]
I tried with kernel 2.4.25 + lowlatency patch.
I have the same xruns :-/
Any other idea ?
checklist:
* running jackd as root? with -R option?
* tried running jackd without any clients?
* IDE-DMA enabled?
* ll-sysctl interface chosen at kernel build time? turned it on?
* X
[Jan Depner]
Agreed. But the problem that keeps popping up on the lists is that
people who are not doing live sound, have cards that do hardware
monitoring, and don't need to use a tiny buffer size waste their time
trying to get the minimum buffer size because they think they need to
get
73 matches
Mail list logo
