[Alsa-devel] lib version?
Ok, here's my stupid question of the day: Is there any way for a program to query the alsa-lib to determine the version number? Ie... Assuming I'm using the relase of alsa-lib-1.0.4, I'd like to query and get back something that would indicate that I'm using that release (and I don't even care so much if my program is what queries it, I just need some way to figure what version the libasound.so.2.0.0 file is). Basically here's the senerio I've got: We've been developing a box for quite a while using alsa, and we've gone through regular upgrades of alsa on each release. Unfortunately I'm trying to track down a rather serious problem in my client program, but I'm getting stymied due to what I suspect is a library version mismatch. I got my program hacked up and working ok to a point and then it segfaults. I replace libasound with a known 1.0.4 and it fails earlier in a different way (perhaps due to one of my hacks to get it working on whatever lib version I had in there). I'm just trying to figure out why... and knowing the library version # might get me there. Any help would be appreciated. Thanks, - Steve --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Lib API documentation
Hey, The library API documentation looks to be out of date. Going to: http://www.alsa-project.org/documentation.php3#Library and clicking on the latest on-line documentation link: http://www.alsa-project.org/alsa-doc/alsa-lib/ gives me documentation that was generated on Nov 25, 2003. I notice that various entries seem to be out of date (specifically looking at the entries for snd_pcm_hw_params_get_rate() which doesn't return the values as described in the doc). While I can and will generate my own documentation locally, it would be nice if someone with access to the web site could regenerate the docs so the public ones match. Thanks, - Steve --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA 1.0.0rc1 released
We went ahead and added code to our alsa client software to cleanly return to a PCM value of 0 and then stuffed a full buffer worth of 0s into the buffer before closeing the PCM in order to solve our pop problem. I'm not sure how the OSS emulation stuff works since we don't use it, but maybe it could use this same treatment? I'm assuming we don't want to change OSS client programs to fix it, so that would leave something in the emulation layer that should be changed. Perhaps OSS automagically does this cleanup? Mark, have you tried using the real OSS? Do the pops happen with OSS? Also, it seems strange to have to do this in client programs when the problem is with specific cards/chipsets not doing their own cleanup. Maybe the drivers of the cards should do the cleanup so the client software doesn't have to know what card they're running on? Just putting this forward for discussion, not voluteering to do the work (I've already got my hands full with the serial MIDI driver, thanks). :) - Steve Mark Knecht wrote: Hi, I want to report that I've built alsa-1.0.0rc1 under Gentoo with q 2.4.20-r7 kernel. Thanks to Thomas Charbonnel for the help with the ebuilds. If any other Gentoo users need the ebuilds, then contact me off list. Unfortunately this release does not impact my loud glitch/pop noise on the HDSP 9652 when using OSS applications. The results are the same as I reported over the last few weeks. I have not run significant Alsa audio yet to talk about how that's working. The OSS fix was the one I was most hoping for, and I haven't had many Alsa problems anyway. - Thanks, Mark On Mon, 2003-12-01 at 05:54, Takashi Iwai wrote: Hi, today we reached ALSA 1.0.0rc1 release. as its name stands, this is the release candidate for 1.0.0. if no show-stopper bug is reported, we'll release 1.0.0 really soon. this version includes the following fixes since the last 1.0.0-pre3 release. Drivers: - fixed OSS emulation on kernel. quake and wine should work now. SNIP --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] [PATCH] serial-u16550 driver. Fixes buffer blocking bug (2nd try)
Takashi,
I've completed my changes on the serial-u16550 driver. I have
implemented most of your suggestions to my previous patch. Now:
* There is a user selectable flag droponfull. Set to 1 and
any new bytes delivered to the driver after the buffer fills
up will be discarded until the buffer is able to flush some
bytes.
* If droponfull==0 (or is not set, the default is 0), the driver
proceeds to block further input by not calling
snd_rawmidi_transmit_ack() and aborting the attempt. It will
try again later.
* I've redone a bit of the interface for the buffer routines.
This was done to support the proper blocking/non-blocking methods
as spelled out above, and to try to protect the buffer data a bit.
So, if droponfull==0, we operate as originally desired (but the
original implementation was broken a bit and this fixes it). If
droponfull==1 we now discard new bytes if our buffer is full; this
behavior fixes the driver hang problem we were having.
The changes should have no material effect on the SNDRV_SERIAL_MS124W_MB
device, and all others should still work well, though we can only
test with the SNDRV_SERIAL_GENERIC.
Please commit this at your earliest opportunity.
Thanks,
- Steve
Change log entry: Fixes problem where buffers fill up with SNDRV_SERIAL_GENERIC
adaptor
when device doesn't signal CTS by dropping new bytes if the module
parameter droponfull == 1.
Index: serial-u16550.c
===
RCS file: /cvsroot/alsa/alsa-kernel/drivers/serial-u16550.c,v
retrieving revision 1.22
diff -u -p -r1.22 serial-u16550.c
--- serial-u16550.c 14 Oct 2003 13:08:13 - 1.22
+++ serial-u16550.c 3 Dec 2003 01:14:42 -
@@ -63,6 +63,9 @@ static char *adaptor_names[] = {
Generic
};
+#define SNDRV_SERIAL_NORMALBUFF 0 /* Normal blocking buffer operation */
+#define SNDRV_SERIAL_DROPBUFF 1 /* Non-blocking discard operation */
+
static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX; /* Index 0-MAX */
static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR; /* ID for this card */
static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE; /* Enable this card */
@@ -73,6 +76,7 @@ static int base[SNDRV_CARDS] = {[0 ... (
static int outs[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 1}; /* 1 to 16 */
static int ins[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 1}; /* 1 to 16 */
static int adaptor[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] =
SNDRV_SERIAL_SOUNDCANVAS};
+static int droponfull[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS -1)] =
SNDRV_SERIAL_NORMALBUFF };
MODULE_PARM(index, 1- __MODULE_STRING(SNDRV_CARDS) i);
MODULE_PARM_DESC(index, Index value for Serial MIDI.);
@@ -99,6 +103,9 @@ MODULE_PARM(outs, 1- __MODULE_STRING(S
MODULE_PARM_DESC(outs, Number of MIDI outputs.);
MODULE_PARM(ins, 1- __MODULE_STRING(SNDRV_CARDS) i);
MODULE_PARM_DESC(ins, Number of MIDI inputs.);
+MODULE_PARM(droponfull, 1- __MODULE_STRING(SNDRV_CARDS) i);
+MODULE_PARM_DESC(droponfull, Flag to enable drop-on-full buffer mode);
+MODULE_PARM_SYNTAX(droponfull, SNDRV_ENABLED , SNDRV_BOOLEAN_FALSE_DESC);
MODULE_PARM_SYNTAX(outs, SNDRV_ENABLED ,allows:{{1,16}},dialog:list);
MODULE_PARM_SYNTAX(ins, SNDRV_ENABLED ,allows:{{1,16}},dialog:list);
@@ -163,6 +170,7 @@ typedef struct _snd_uart16550 {
int buff_in_count;
int buff_in;
int buff_out;
+int drop_on_full;
// wait timer
unsigned int timer_running:1;
@@ -194,12 +202,15 @@ inline static void snd_uart16550_del_tim
inline static void snd_uart16550_buffer_output(snd_uart16550_t *uart)
{
unsigned short buff_out = uart-buff_out;
- outb(uart-tx_buff[buff_out], uart-base + UART_TX);
- uart-fifo_count++;
- buff_out++;
- buff_out = TX_BUFF_MASK;
- uart-buff_out = buff_out;
- uart-buff_in_count--;
+ if( uart-buff_in_count 0 )
+ {
+ outb(uart-tx_buff[buff_out], uart-base + UART_TX);
+ uart-fifo_count++;
+ buff_out++;
+ buff_out = TX_BUFF_MASK;
+ uart-buff_out = buff_out;
+ uart-buff_in_count--;
+ }
}
/* This loop should be called with interrupts disabled
@@ -257,9 +268,12 @@ static void snd_uart16550_io_loop(snd_ua
|| uart-adaptor == SNDRV_SERIAL_GENERIC) {
/* Can't use FIFO, must send only when CTS is true */
status = inb(uart-base + UART_MSR);
- if (uart-fifo_count == 0 (status UART_MSR_CTS)
-uart-buff_in_count 0)
- snd_uart16550_buffer_output(uart);
+ while( (uart-fifo_count == 0) (status UART_MSR_CTS)
+ (uart-buff_in_count 0) )
+ {
+ snd_uart16550_buffer_output(uart);
+ status = inb( uart-base + UART_MSR );
+ }
} else {
/* Write loop */
[Alsa-devel] Pops at start of song
All,
We're having a problem with some of our audio applications. When a song
starts playing we will often hear a loud pop out of the speakers before
it plays audio. It seems dependent upon where we stoped and the specfic
content of the last song, if we hit our stop control and abort in the
middle of the song it may pop uppon restarting or starting a new song.
One of our engrs found if he fills the entire buffer with zeros before
quitting the program, on the next start it won't pop (though that moves
the pop to the end of the previous due to a disconnect/jump in the
created waveform). Unless this is a hardware issue, this doesn't seem
to be the right solution to me. So:
* What are things that we can do in our program using the alsa pcm
functions to eliminate this? Maybe a specific function we need to call
or a particular sequence?
* Or, is this something inherent in hardware and other than filling with
zeros before we quit there's nothing we can do?
I figure some of you have encountered this before, so maybe there's some
ideas out there?
If you're wondering what we do when a stop command comes in: pretty
much nothing. Basically my ALSASender routine ends and calls:
void CDSP::ClosePCM( void )
{
// some other bookkeeping goes here snip
snd_pcm_close( hPCM );
if( mPCMStatus )
{
snd_pcm_status_free( mPCMStatus );
mPCMStatus = NULL;
}
// Non-alsa related cleanup goes here snip
}
Also, note that we do get the same pops with using aplay.
Thanks,
- Steve
PS Takashi - I haven't given up on my serial driver patch, I was
working on it when I got interupted with something else, it should be on
its way soon; thanks for your help.
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Pops at start of song
Mark,
I don't know if it's the same effect or not. We're working on an
embedded Linux device. It has a full Linux kernel and basically is a
hand-built distribution of stock Linux stuff, but is very stripped down
and some of our apps are custom. As we're not using OSS in any way
(neither apps nor the Alsa OSS emulation layer) so I can't speak to that.
One of our engrs here seems to think it's a hardware issue also, and the
only way to get our apps to deal with it is to on the stop command push
values into the pcm buffer that ramp down to 0 and then fill a full
buffer-size number of samples of 0 into the buffer before closeing it.
I'm not sure I agree (if it HW based, then yes I agree) and was hoping
there was an approprate alsa-way. Our device is one of those mini-itx
via based boards (frequently seen mentioned on /.). It seems it uses
VIA 82xx audio.
Your problem sounds more like a configuration or hardware issue, unlike
ours which I'm guessing is either a hardware or actual (non-alsa) source
code issue. Sorry I can't be of more help, but hopefully someone here
can help, and I'll let you know what we find if anything.
Thanks,
- Steve
Mark Knecht wrote:
Steve,
You're the first person I can remember to report something very similar
to what I'm dealing with every day. I get a huge loud cracking noise at the
start of any audio operation that is not vanilla Alsa - i.e. - anything
accessing OSS I think. In my case I think it's hardware based, but I'm not
sure. This happens only on my HDSP 9652 system. I have two other systems,
one using an onboard NForce audio device, and the other using an RME
Hammerfall Light, that act correctly.
With the RME products we have the hdspconf application which shows the
sync frequency of the card. I normally run at 44.1K, but if I open hdspconf
and watch the card's frequency, it tells me that the card becomes unlocked
and changes sample rates when the noise happens. This happens when starting
any app that uses OSS (I think) like gxine, or xmms, or most games, or
browsing web pages. It does not happen when starting a native Alsa
application like alsaplayer.
Does this sound at all like what you're experiencing?
- Mark
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Steve
deRosier
Sent: Wednesday, November 19, 2003 2:15 PM
To: [EMAIL PROTECTED]
Subject: [Alsa-devel] Pops at start of song
All,
We're having a problem with some of our audio applications. When a song
starts playing we will often hear a loud pop out of the speakers before
it plays audio. It seems dependent upon where we stoped and the specfic
content of the last song, if we hit our stop control and abort in the
middle of the song it may pop uppon restarting or starting a new song.
One of our engrs found if he fills the entire buffer with zeros before
quitting the program, on the next start it won't pop (though that moves
the pop to the end of the previous due to a disconnect/jump in the
created waveform). Unless this is a hardware issue, this doesn't seem
to be the right solution to me. So:
* What are things that we can do in our program using the alsa pcm
functions to eliminate this? Maybe a specific function we need to call
or a particular sequence?
* Or, is this something inherent in hardware and other than filling with
zeros before we quit there's nothing we can do?
I figure some of you have encountered this before, so maybe there's some
ideas out there?
If you're wondering what we do when a stop command comes in: pretty
much nothing. Basically my ALSASender routine ends and calls:
void CDSP::ClosePCM( void )
{
// some other bookkeeping goes here snip
snd_pcm_close( hPCM );
if( mPCMStatus )
{
snd_pcm_status_free( mPCMStatus );
mPCMStatus = NULL;
}
// Non-alsa related cleanup goes here snip
}
Also, note that we do get the same pops with using aplay.
Thanks,
- Steve
PS Takashi - I haven't given up on my serial driver patch, I was
working on it when I got interupted with something else, it should be on
its way soon; thanks for your help.
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Pops at start of song
Hm, sounds like the very definition of a hardware issue to me. ;) When I
said hardware issue I wasn't refering to a bug in the hardware or
hardware drivers... more of a that's how it works and we're stuck with
it. :)
One of our other engineers has taken that exact approach. It just seems
strange to have to manually ramp down the voltage on the hw by the
application manually inserting data into the pcm to do so. If this has
to be done w/ some soundcards and not others, why is the application
resposible for this and not the driver or the alsa-lib? I just figured
it was unique with the fact we pretty much didn't do anything other than
a snd_pcm_close() after our last snd_pcm_writei() call and that there
were some type of snd_pcm_cleanup_everything() call that we need to make.
Thanks,
- Steve
Apostolos Dimitromanolakis wrote:
Hi,
This is not a hardware issue. The problem is that the DAC of your card
gets stopped in some other level than 0V and when you restart playback
the voltage differential causes the pop (because the output of the
digital to analog converter is AC-coupled). To perform a clean stop and
start make sure that when you start the playback, the first few bytes
are zero and when you stop the last few. If they are not, do a gradual
change of the samples (say no more that +/- 500 difference over the
previous sample). I think the problem is more evident in high end
sound-cards which have a flat frequency response down to a few Hz.
Apostolos
Steve deRosier wrote:
All,
We're having a problem with some of our audio applications. When a
song starts playing we will often hear a loud pop out of the speakers
before it plays audio. It seems dependent upon where we stoped and
the specfic content of the last song, if we hit our stop control and
abort in the middle of the song it may pop uppon restarting or
starting a new song.
One of our engrs found if he fills the entire buffer with zeros before
quitting the program, on the next start it won't pop (though that
moves the pop to the end of the previous due to a disconnect/jump in
the created waveform). Unless this is a hardware issue, this doesn't
seem to be the right solution to me. So:
* What are things that we can do in our program using the alsa pcm
functions to eliminate this? Maybe a specific function we need to
call or a particular sequence?
* Or, is this something inherent in hardware and other than filling
with zeros before we quit there's nothing we can do?
I figure some of you have encountered this before, so maybe there's
some ideas out there?
If you're wondering what we do when a stop command comes in: pretty
much nothing. Basically my ALSASender routine ends and calls:
void CDSP::ClosePCM( void )
{
// some other bookkeeping goes here snip
snd_pcm_close( hPCM );
if( mPCMStatus )
{
snd_pcm_status_free( mPCMStatus );
mPCMStatus = NULL;
}
// Non-alsa related cleanup goes here snip
}
Also, note that we do get the same pops with using aplay.
Thanks,
- Steve
PS Takashi - I haven't given up on my serial driver patch, I was
working on it when I got interupted with something else, it should be
on its way soon; thanks for your help.
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [PATCH] serial-u16550 driver. Fixes buffer blocking bug
Takashi Iwai wrote:
At Thu, 30 Oct 2003 13:33:37 -0800,
Steve deRosier wrote:
Takashi,
Thanks for your response. I've addressed your issues below. Let's
discuss this and if necessary I'll modify my fix.
1. Move all checks of buffer overflow and such to the
actual buffer write and read routines. This makes
the buffer routines more robust and encaspulates buffer
opperations better.
the check in the caller may be still needed for the multi-bytes write
(e.g. for switching the port). otherwise, the port-switch command
can be mixed and messed up when the device is accessed concurrently.
I thought about this, but decided it's not a large issue since it is
mitigated by the natural operation of the driver.
For normal opperation: As this is called with interupts off, the
process can't be interupted. The function doesn't return until after
we've drained the snd_rawmidi_transmit(), and if we do decide to insert
a f5... msg, we do the whole msg before we can return. So, no issue
durring normal opperation. So concurrent access doesn't apear to be a
large issue.
yes, normally it's ok. the problem would be only the full-buffer
state.
Ok, as you don't seem swayed by my argument, I'll go ahead and put a
check in that will address the issue, but not break other things.
2. Always try to send data to the buffers. Don't interupt
normal opperation of the algoritim because buffers are full.
This was what was actually causing the data to be left in
rawmidi and thus causing it to lock up. This is helped
by moving the buffer size checks into the routines.
this is the questionary behavior.
the fact that the local buffer is full means that the transfer doesn't
work. so, it is quite correct behavior that rawmidi blocks the
further write (in blocking mode), i think. and, it should return
-EAGAIN in non-blocking mode.
or, at least, we can make the behavior selectable: abandon or block.
Well, the driver already was trying to opperate in the mode where it was
abandoning bytes, it was just doing a bad job of it. All I did was fix
it so it actually abandoned all bytes that didn't fit in the buffers.
Before it was grabbing a byte from snd_rawmidi_transmit() and if no room
was in the buffer it would break out of the while(1) loop. So,
basically it would abandon the first byte on its execution, but leave
some data there for later. This caused a problem with rawmidi's buffers
seeming to back up and eventually hanging up the driver (recoverable
only via reopening the device).
basically, the data should NOT be abandoned as long as it can be
held. the current code is not good from this perspective.
it should be something like:
while (snd_rawmidi_transmit_peek(substream, byte, 1) == 1) {
if (! writable())
break;
write_byte(byte);
snd_rawmidi_transmit_ack(substream, 1);
}
So, should the driver not be using the snd_rawmidi_transmit() function,
and instead doing its own thing. Perhaps this would be more proper and
would make it work better. It'll require a larger re-work of the
relevant driver function, but I think it'll be worth it.
The program (call it pdr) we have using this device operates in blocking
mode. So, if things worked properly, pdr would attempt to write the
midi msg, and the snd_seq_event_output() just wouldn't return until it
was able to send the data. That would be fine. BUT, if we physically
disconnect the serial cable from the device, after awhile, the buffer in
serial-u16550.c fills up, then one byte is retrieved from
snd_rawmidi_transmit() (and then discarded by the driver) for every
three bytes put into the rawmidi buffers, these buffers fill up and
eventually cause the lockup of the driver, all while never reporting a
problem back to pdr (snd_seq_event_output() seems not to block even
though we're in blocking mode).
in this case, the operation is blocked because it's really blocked.
sure, it doesn't report errors because it's just the blocking
behavior. the driver doesn't detect the disconnection, and it simply
waits until the next transfer is available.
I don't think you're understanding what I'm telling you. pdr doesn't
get blocked even though we don't set SND_SEQ_NONBLOCK mode on. It calls
the snd_seq_event_output() and that ALWAYS returns. In the condition
that the buffer fills up, and then the system is reconnected and drains
the buffer, after that any more writes that pdr sends out that go
through rawmidi's buffers never happen. All send direct output will
still work however.
It really doesn't matter to our app if it gets blocked or is not blocked
or if bytes get discarded during a physical cable disconnection, the way
it is designed it continues to grind on anyway and as such, when
reconnected and the buffer drains eventually all would be right with the
world again. BUT, something in Alsa breaks down in this instance and
doesn't just clear up
Re: [Alsa-devel] [PATCH] serial-u16550 driver. Fixes buffer blocking bug
Takashi, Thanks for your response. I've addressed your issues below. Let's discuss this and if necessary I'll modify my fix. 1. Move all checks of buffer overflow and such to the actual buffer write and read routines. This makes the buffer routines more robust and encaspulates buffer opperations better. the check in the caller may be still needed for the multi-bytes write (e.g. for switching the port). otherwise, the port-switch command can be mixed and messed up when the device is accessed concurrently. I thought about this, but decided it's not a large issue since it is mitigated by the natural operation of the driver. For normal opperation: As this is called with interupts off, the process can't be interupted. The function doesn't return until after we've drained the snd_rawmidi_transmit(), and if we do decide to insert a f5... msg, we do the whole msg before we can return. So, no issue durring normal opperation. So concurrent access doesn't apear to be a large issue. If buffer gets full: Yes, it is possible for an f5... msg to get interupted. BUT, I don't see this as a large problem. On return to normal opperation (ie. the buffer begins draining again), the proper port-switch command will be written in correctly when the port gets switched, or in the next three seconds, whichever comes first. Perhaps some data gets sent to the wrong port, but it autocorrects very quickly. While this condition technically is possible, I haven't seen it happen in practice, and even if it does it would correct itself quickly. For another mittigating factor, please see my answer to #2 below. If you're still concerned about this, I have an alternate fix that would keep a check, but not interfeare with opperation. 2. Always try to send data to the buffers. Don't interupt normal opperation of the algoritim because buffers are full. This was what was actually causing the data to be left in rawmidi and thus causing it to lock up. This is helped by moving the buffer size checks into the routines. this is the questionary behavior. the fact that the local buffer is full means that the transfer doesn't work. so, it is quite correct behavior that rawmidi blocks the further write (in blocking mode), i think. and, it should return -EAGAIN in non-blocking mode. or, at least, we can make the behavior selectable: abandon or block. Well, the driver already was trying to opperate in the mode where it was abandoning bytes, it was just doing a bad job of it. All I did was fix it so it actually abandoned all bytes that didn't fit in the buffers. Before it was grabbing a byte from snd_rawmidi_transmit() and if no room was in the buffer it would break out of the while(1) loop. So, basically it would abandon the first byte on its execution, but leave some data there for later. This caused a problem with rawmidi's buffers seeming to back up and eventually hanging up the driver (recoverable only via reopening the device). The program (call it pdr) we have using this device operates in blocking mode. So, if things worked properly, pdr would attempt to write the midi msg, and the snd_seq_event_output() just wouldn't return until it was able to send the data. That would be fine. BUT, if we physically disconnect the serial cable from the device, after awhile, the buffer in serial-u16550.c fills up, then one byte is retrieved from snd_rawmidi_transmit() (and then discarded by the driver) for every three bytes put into the rawmidi buffers, these buffers fill up and eventually cause the lockup of the driver, all while never reporting a problem back to pdr (snd_seq_event_output() seems not to block even though we're in blocking mode). As far as pdr seems to know, it's able to always send data, but eventually the data stops getting to the physical device (as a side note, midi data that avoids the rawmidi buffers via snd_seq_event_output_direct() will get written to the device properly even in this case). So, now the driver reliably drops all data given to it if the buffers are full, not just some of the data and rawmidi buffers never get backed up, the driver doesn't lockup and everything works properly when the device gets pluged back in. Personally, I feel it IS proper behavior. Simple fact is, if the condition happens where this buffer gets filled in, the midi events have been released by alsa to go out to the device immedately, but have now been delayed by up to 30-40 minutes. They're past their prime and are really no longer relevant. If we discard data, well, tough. At this point it becomes about error recovery, not valid data. This code recovers proper opperation, where the old code didn't. This method works best for our application. However, if we want different behavior, let me know how to do this. I was able to fix the problem here, without digging further into the rawmidi code or even further up the chain. Frankly I'm not educated enough on that
[Alsa-devel] [PATCH] serial-u16550 driver. Fixes buffer blocking bug
I am submitting a patch to the serial-u16550 driver fix a bug
that we have encountered. Basically, when using the
SNDRV_SERIAL_GENERIC adaptor in the serial-u16550 MIDI driver,
if the device becomes unplugged or some other condition where
the device stops signaling CTS, the send buffer backs up.
This is fine and expected opperation, except on a prolonged
problem (with our music, about 30-40 minutes typically) the
buffer itself gets full. It is supposed to then just throw
away data, but it seems that it doesn't operate quite right
and it ends up backing up data in rawmidi. When this
happens, the driver basically locks up (though send direct
data still gets out), and only on a close and reopen of the
device will recover.
This patch fixes the problem, by modifiying how it checks
for and handles its internal buffer:
1. Move all checks of buffer overflow and such to the
actual buffer write and read routines. This makes
the buffer routines more robust and encaspulates buffer
opperations better.
2. Always try to send data to the buffers. Don't interupt
normal opperation of the algoritim because buffers are full.
This was what was actually causing the data to be left in
rawmidi and thus causing it to lock up. This is helped
by moving the buffer size checks into the routines.
3. When able to write, drain output as necessary instead of
only writing one byte at a time. This was causing us to
backup eventually anyway since we usually write more than
one byte of data.
This fixes a bug that we were encountering in the driver,
and I'm pretty sure it shouldn't cause any problems
with the other devices that use this driver. If anyone has
the other devices to test on, please test away.
Thanks,
- Steve
--
Change log entry: Fixes problem where buffers fill up with SNDRV_SERIAL_GENERIC
adaptor
when device doesn't signal CTS.
Index: serial-u16550.c
===
RCS file: /home/cvsroot/alsa/alsa-kernel/drivers/serial-u16550.c,v
retrieving revision 1.22
diff -c -3 -p -r1.22 serial-u16550.c
*** serial-u16550.c 2003/10/14 13:08:13 1.22
--- serial-u16550.c 2003/10/29 21:19:08
*** inline static void snd_uart16550_del_tim
*** 194,205
inline static void snd_uart16550_buffer_output(snd_uart16550_t *uart)
{
unsigned short buff_out = uart-buff_out;
! outb(uart-tx_buff[buff_out], uart-base + UART_TX);
! uart-fifo_count++;
! buff_out++;
! buff_out = TX_BUFF_MASK;
! uart-buff_out = buff_out;
! uart-buff_in_count--;
}
/* This loop should be called with interrupts disabled
--- 194,208
inline static void snd_uart16550_buffer_output(snd_uart16550_t *uart)
{
unsigned short buff_out = uart-buff_out;
! if( uart-buff_in_count 0 )
! {
! outb(uart-tx_buff[buff_out], uart-base + UART_TX);
! uart-fifo_count++;
! buff_out++;
! buff_out = TX_BUFF_MASK;
! uart-buff_out = buff_out;
! uart-buff_in_count--;
! }
}
/* This loop should be called with interrupts disabled
*** static void snd_uart16550_io_loop(snd_ua
*** 257,265
|| uart-adaptor == SNDRV_SERIAL_GENERIC) {
/* Can't use FIFO, must send only when CTS is true */
status = inb(uart-base + UART_MSR);
! if (uart-fifo_count == 0 (status UART_MSR_CTS)
!uart-buff_in_count 0)
! snd_uart16550_buffer_output(uart);
} else {
/* Write loop */
while (uart-fifo_count uart-fifo_limit /* Can we write ? */
--- 260,271
|| uart-adaptor == SNDRV_SERIAL_GENERIC) {
/* Can't use FIFO, must send only when CTS is true */
status = inb(uart-base + UART_MSR);
! while( (uart-fifo_count == 0) (status UART_MSR_CTS)
!(uart-buff_in_count 0) )
! {
! snd_uart16550_buffer_output(uart);
! status = inb( uart-base + UART_MSR );
! }
} else {
/* Write loop */
while (uart-fifo_count uart-fifo_limit /* Can we write ? */
*** static int snd_uart16550_output_close(sn
*** 579,591
inline static void snd_uart16550_write_buffer(snd_uart16550_t *uart, unsigned char
byte)
{
unsigned short buff_in = uart-buff_in;
! uart-tx_buff[buff_in] = byte;
! buff_in++;
! buff_in = TX_BUFF_MASK;
! uart-buff_in = buff_in;
! uart-buff_in_count++;
! if (uart-irq 0) /* polling mode */
! snd_uart16550_add_timer(uart);
}
static void snd_uart16550_output_byte(snd_uart16550_t *uart, snd_rawmidi_substream_t
* substream, unsigned char midi_byte)
--- 585,600
inline static void snd_uart16550_write_buffer(snd_uart16550_t *uart, unsigned char
Re: [Alsa-devel] negative timestamps on pcm?!?
when the state is OPEN, these values are bogus, since snd_pcm_status() returns immediately without putting the values. So, alsa writes bogus data to the proc entries? Maybe it shouldn't write bad data, just leave the spots blank, initilize with 0's or something else? - hw_ptr : 26942906 appl_ptr: 26942906 they are real values. i can't remember any reason of the restriction above. i think it's ok to remove it. What restriction is that? It seems that our ogg player is set to blocking behavior and each one is blocked on the call to open the pcm. The intrieging thing is the timestamp is negative. It jumped out that this just looks wrong! Hypothesis 1: After a really long time playing, the timestamp on the pcm wraps to negative. alsa can't handle this and blocks on the output. It's no longer running, but is still in an OPEN state so nothing else can open it. alsa should either use an unsigned value so large that it is impossable to overflow (???), use an unsigned and detect overflow and handle it gracefully, or use a signed value and detect the overflow/wrap and handle it. Hypothesis 2: We're barking up the wrong tree and the only thing wrong is that the proc entry is formmated poorly. (but even if that is the case, the problem still happens where after prolonged time alsa stops us). at least, the values above make no sense. Right, the values make no sense, but I think we've explained that away now. So, what is causing alsa to eventually stop playing right? Yes, that's not exactly a fair question... where should we start looking? Maybe a mutex, race condition, or an off-by-one error somewhere? which version of ALSA driver are you using? Driver: 0.9.7c Library: 0.9.7 (retrieved from the website just a few days ago) Thanks, - Steve --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] negative timestamps on pcm?!?
All, We've noticed a problem with the newest version of Alsa while doing some stress testing of our devices. Basically, the scenerio is we're playing through a large library of .ogg files over the weekend. When we checked on the progress upon getting in on Monday, we discovered that the PCM had ceased playing, and our ogg player had started a ton of instances (one for each song it was supposed to play) and couldn't play on any of them. Looking at /proc/asound/card0/pcm0p/sub0/status: # cat status state: OPEN trigger_time: 642.0 tstamp : -1071072720.-1071072332 delay : 498 avail : -1072507698 avail_max : -1071072720 - hw_ptr : 26942906 appl_ptr: 26942906 It seems that our ogg player is set to blocking behavior and each one is blocked on the call to open the pcm. The intrieging thing is the timestamp is negative. It jumped out that this just looks wrong! Hypothesis 1: After a really long time playing, the timestamp on the pcm wraps to negative. alsa can't handle this and blocks on the output. It's no longer running, but is still in an OPEN state so nothing else can open it. alsa should either use an unsigned value so large that it is impossable to overflow (???), use an unsigned and detect overflow and handle it gracefully, or use a signed value and detect the overflow/wrap and handle it. Hypothesis 2: We're barking up the wrong tree and the only thing wrong is that the proc entry is formmated poorly. (but even if that is the case, the problem still happens where after prolonged time alsa stops us). This didn't happen with earlier versions of alsa using the same playing software. I hope this helps the developers in tracking down any bugs. Thanks, - Steve --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] No sound with ladspa plugin in newer alsa versions
Jaroslav,
You've probably been distracted with more pressing matters, but are you
still looking at this issue? I'd be happy to look into it or fix it
myself if you could give me some ideas of where/what/how to fix it.
Thanks,
- Steve
Steve deRosier wrote:
Jaroslav, thanks for replying. I'm not 100% sure that my setup is right
(it was quoted in the origional email), but since it used to work with
these setings, but now doesn't...?...
I've looked over both the setup in my asound.conf and the output from
the verbose mode aplay and I have nearly the same stuff as you show.
Here's the setup out of my /etc/asound.conf file:
# cat /etc/asound.conf
pcm.pd
{
type ladspa
slave.pcm plughw:0,0
path /lib/ladspa
plugins
[
{
label amPitchshift
input
{
controls [ 0.890899 3 ]
}
}
]
}
And the aplay output:
# aplay -v -D plug:pd alla_luce.wav
aplay: /lib/libasound.so.2: no version information available (required
by aplay)
Playing WAVE 'alla_luce.wav' : Signed 16 bit Little Endian, Rate 44100
Hz, Stereo
Plug PCM: Linear Integer - Linear Float conversion PCM (FLOAT_LE)
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat: STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 16384
period_size : 4096
period_time : 92879
tick_time: 1
tstamp_mode : NONE
period_step : 1
sleep_min: 0
avail_min: 4096
xfer_align : 4096
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
Slave: LADSPA PCM
Control input port initial values: 0 = 0.89089900 1 = 3.
Its setup is:
stream : PLAYBACK
access : MMAP_NONINTERLEAVED
format : FLOAT_LE
subformat: STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 32
buffer_size : 16384
period_size : 4096
period_time : 92879
tick_time: 1
tstamp_mode : NONE
period_step : 1
sleep_min: 0
avail_min: 4096
xfer_align : 4096
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
Slave: Plug PCM: Linear Integer - Linear Float conversion PCM (S16_LE)
Its setup is:
stream : PLAYBACK
access : MMAP_NONINTERLEAVED
format : FLOAT_LE
subformat: STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 32
buffer_size : 16384
period_size : 4096
period_time : 92879
tick_time: 1
tstamp_mode : NONE
period_step : 1
sleep_min: 0
avail_min: 4096
xfer_align : 4096
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
Slave: Hardware PCM card 0 'VIA 82C686A/B rev50' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat: STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 16384
period_size : 4096
period_time : 92879
tick_time: 1
tstamp_mode : NONE
period_step : 1
sleep_min: 0
avail_min: 4096
xfer_align : 4096
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
Aborted by signal Interrupt...
#
Anymore ideas?
Thanks,
- Steve
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] No sound with ladspa plugin in newer alsa versions
Well, after getting no responses, I've spent the last 40 some hours at
work tracking the problem down. I've got some more information and some
more specific questions so someone might be able to help this time.
I've managed to narrow down the problem with ladspa plugins. Since it
used to work, but doesn't any more I figured if I could find the
specific change I would be able to get an idea where to look to fix the
problem. I checked out 20 some CVS versions, built and patched them as
necessary to get things working and found that the ladspa plugins were
broken on 2/4/2003. CVS of 2003-02-04 at midnight worked, but CVS of
2003-02-05 didn't. After diffing and then replacing new code with old
on a change by change basis, I found that snd_pcm_plugin_mmap() and
snd_pcm_plugin_munmap() in alsa-lib/src/pcm/pcm_plugin.c were stubbed
out and marked ATTRIBUTE_UNUSED (aparently durring some of perex's DMix
plugin changes). Problem is, pcm_ladspa.c and others seem to still use
these functions. Adding these functions back into my checked out cvs
2/5/2003 version and ladspa plugins magically start working again.
But, alas, things are not this easy. I took my src copy of the 0.9.6
release (I can't seem to get a current CVS to compile, it complains
about a missing alsa-lib/src/userfile.c file) and put the functions back
in (added the meat and removed the attribute), compiled and tested. I
now get sound out but it's all garbled.
After looking a bit at pcm_ladspa.c and doing a few greps I found or
infered that:
1. many of the pcm_{plugintype file here}.c files in there snd_pcm_ops_t
structure variable they set the mmap and munmap fields still use this
ATTRIBUTE_UNUSED function. Line 710 in pcm_ladspa.c.
2. DMix uses it's own version of these functions.
3. I'm infering that since just putting this function back in doesn't
work, that something fundamental has changed with the mmap implmentation
that makes it so the old functions don't work.
I'm guessing that sometime since Feb., there's been some archetectural
changes to some of the plugin stuff to get DMix working. But, the other
portions, including ladspa support, haven't kept up with the changes
made and so are broken (am I the ONLY person trying to get ladspa
plugins working with Alsa?). I'd like to get this fixed. I'm perfectly
happy to do the work myself, but I don't know enough of how Alsa works
in order to get this done.
Here's what I understand: I'm getting the idea that each plugin type,
when it is parsed in the config file, gets setup. I presume that the
_snd_pcm_ladspa_open() function is the entry point for the ladspa stuff.
It opens and does some stuff then it uses the snd_pcm_ops_t structure
to tell the pcm stuff what functions to call in order to get things done
when working with this plugin. Kinda a OOP without C++ concept with the
pcm_ladspa.c module as the ladspa plugin handler object. Origionally
it seems that the pcm_plugin.c module was to provide the basic
functionality for all the plugins, and then pcm_ladspa.c could override
or use those functions in it's snd_pcm_ops_t as it needed to.
So, if I was to fix this, I see two potential courses of action:
1. I can put meat back into the snd_pcm_plugin_mmap() ..._munmap()
functions and then fix it to make it work with the newer stuff so that I
both get sound out and it comes out properly.
2. I can create my own snd_pcm_ladspa_mmap() and ..._munmap() functions
and use those.
In either situation, I don't have a clue what I need to put in these
functions to make them work. Or even how they really fit into the
structure of how things work with the pcm system. I don't know enough
about Alsa internals to hack this easily (though I'm finding I'm quickly
being forced to learn).
So, can someone either fix this for me
or,
please educate me enough on what I need to do to make this work so I can
fix it myself and give you guys a patch.
Help, please!?!?
Thanks,
- Steve
Steve deRosier wrote:
All,
I hope that someone here can help with a problem we're having with the
newer versions of the alsa-lib. We are using the ladspa interface with
alsa to use a pitch-shifting plugin. It worked fine with earlier
versions of the alsa lib, but with the newer versions it produces no
sound output. The last version of alsa that we know works (and is the
stable version we're using in our system at the moment because of it)
is 0.9.0rc6. Shortly after this version, the ladspa stuff was broken
(segfault, see the thread starting with:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg07847.html
). The segfault was fixed, but we've not been able to get audio out of
alsa-lib when using the plugin since.
I've been trying to track this down, but I'm out of ideas of what/where
to fiddle with. We really want to move to more current versions of
alsa, as working with out-of-date versions is causing us other
headaches, but we can't till we fix this problem.
One
Re: [Alsa-devel] No sound with ladspa plugin in newer alsa versions
Jaroslav, thanks for replying. I'm not 100% sure that my setup is right
(it was quoted in the origional email), but since it used to work with
these setings, but now doesn't...?...
I've looked over both the setup in my asound.conf and the output from
the verbose mode aplay and I have nearly the same stuff as you show.
Here's the setup out of my /etc/asound.conf file:
# cat /etc/asound.conf
pcm.pd
{
type ladspa
slave.pcm plughw:0,0
path /lib/ladspa
plugins
[
{
label amPitchshift
input
{
controls [ 0.890899 3 ]
}
}
]
}
And the aplay output:
# aplay -v -D plug:pd alla_luce.wav
aplay: /lib/libasound.so.2: no version information available (required
by aplay)
Playing WAVE 'alla_luce.wav' : Signed 16 bit Little Endian, Rate 44100
Hz, Stereo
Plug PCM: Linear Integer - Linear Float conversion PCM (FLOAT_LE)
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat: STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 16384
period_size : 4096
period_time : 92879
tick_time: 1
tstamp_mode : NONE
period_step : 1
sleep_min: 0
avail_min: 4096
xfer_align : 4096
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
Slave: LADSPA PCM
Control input port initial values: 0 = 0.89089900 1 = 3.
Its setup is:
stream : PLAYBACK
access : MMAP_NONINTERLEAVED
format : FLOAT_LE
subformat: STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 32
buffer_size : 16384
period_size : 4096
period_time : 92879
tick_time: 1
tstamp_mode : NONE
period_step : 1
sleep_min: 0
avail_min: 4096
xfer_align : 4096
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
Slave: Plug PCM: Linear Integer - Linear Float conversion PCM (S16_LE)
Its setup is:
stream : PLAYBACK
access : MMAP_NONINTERLEAVED
format : FLOAT_LE
subformat: STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 32
buffer_size : 16384
period_size : 4096
period_time : 92879
tick_time: 1
tstamp_mode : NONE
period_step : 1
sleep_min: 0
avail_min: 4096
xfer_align : 4096
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
Slave: Hardware PCM card 0 'VIA 82C686A/B rev50' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat: STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 16384
period_size : 4096
period_time : 92879
tick_time: 1
tstamp_mode : NONE
period_step : 1
sleep_min: 0
avail_min: 4096
xfer_align : 4096
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
Aborted by signal Interrupt...
#
Anymore ideas?
Thanks,
- Steve
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] No sound with ladspa plugin in newer alsa versions
All,
I hope that someone here can help with a problem we're having with the
newer versions of the alsa-lib. We are using the ladspa interface with
alsa to use a pitch-shifting plugin. It worked fine with earlier
versions of the alsa lib, but with the newer versions it produces no
sound output. The last version of alsa that we know works (and is the
stable version we're using in our system at the moment because of it)
is 0.9.0rc6. Shortly after this version, the ladspa stuff was broken
(segfault, see the thread starting with:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg07847.html
). The segfault was fixed, but we've not been able to get audio out of
alsa-lib when using the plugin since.
I've been trying to track this down, but I'm out of ideas of what/where
to fiddle with. We really want to move to more current versions of
alsa, as working with out-of-date versions is causing us other
headaches, but we can't till we fix this problem.
One interesting thing...alsa uses an older version of the ladspa.h
header. Replaced w/ a more current version and no change though.
I've played with our configuration in asound.conf and no joy. I've
examined the code in src/pcm/pcm_ladspa.c and nothing pops up at me.
I'm currently looking at the source for the plugin, but nothing obvious
is showing itself.
I'd be happy to fix this myself (or get a patch from someone), but I'm
out of ideas of where to look or even how to go about debugging this
particular problem. Maybe it's a configuration problem; Maybe a
problem with pcm_ladspa.c; Maybe a problem with something else that
just happened to change around that time. Any ideas of where I can look
or how I can debug this issue?
Last known working version: 0.9.0rc6
Currently working with: 0.9.6 and a cvs snapshot from last Thursday
(broken in both)
Plugin is from:
http://plugin.org.uk/releases/0.4.2/
In our snd_pcm_open call, our device is:
plug:pd
The plugin we're using is:
/lib/ladspa/am_pitchshift_1433.so
our asound.conf file looks like:
pcm.pd
{
type ladspa
slave.pcm plughw:0,0
path /lib/ladspa
plugins
[
{
label amPitchshift
input
{
controls [ 1.189207 3 ]
}
}
]
}
Thanks,
- Steve
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Sync between MIDI and audio
Paul, Ah, well that explains it. Thanks. Can you point me to some info on how I would link the two clocks (I guess it would be to make the seq use the PCM clock)? As far as using kernel 2.5/2.6 or the backport of the hi-res timers code... unfortunately this isn't an option for me. I can't change the kernel version and even if I could, the rest of the people wouldn't allow it at this point. But, even if I used the hi-res stuff, wouldn't I still have the same problem with having 2 clocks and those drifting apart over time? Thanks, - Steve Paul Davis wrote: The problem: the MIDI and audio start synced up, but after a while they start to drift further and further apart. I've checked my stuff exaustively to make sure that it's not the fault of my program, so I'm figuring it is caused by me not setting up something properly in alsa to make the two streams synced up. you either have to force the sequencer queue to use the PCM device as a clock, or you have to use the RTC as the clock for both (which will cause audio glitches every so often since it drifts w.r.t. the audio clock). you can't expect this to just work - you've created a system with two clocks (the sequencer queue and the PCM device), and such systems will never stay in sync. this is a very tricky area of linux audio/MIDI programming, and my personal advice would be to use kernel 2.5/2.6 or the backport of the hi-res timers code. you can then get usec-accurate scheduling of events (in SCHED_FIFO tasks, anyway) and forget the ALSA queue. hopefully, the ALSA sequencer will at some point take advantage of the new timers. even so, its still not a simple thing to do. --p --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Sync between MIDI and audio
I'm writting an app that plays a special format and uses both the Alsa
seq and pcm interfaces to output MIDI and audio data together. I'm
almost done, but I've got one problem that is plaugeing me: I can't get
the two to stay in sync.
Basically, what I'm doing is using writei() to send frames to the audio
and for midi:
void SendTimeEvent( snd_seq_event_t *event, snd_seq_real_time_t *iRealTime)
{
snd_seq_ev_set_source( event, mPort );
snd_seq_ev_set_subs(event);
snd_seq_ev_schedule_real(event, mQueue, 0, iRealTime );
snd_seq_event_output(hSeq, event);
snd_seq_drain_output(hSeq);
}
I call this with iRealTime calculated based on the number of frames I've
sent to the audio. I recieve the MIDI data and the audio samples in
sync from a different portion of the program, and the time that the MIDI
should be played at is the time that sample gets played plus a constant
offset.
Both the MIDI and audio play just fine (the piano plays and so does the
digital audio).
The problem: the MIDI and audio start synced up, but after a while they
start to drift further and further apart. I've checked my stuff
exaustively to make sure that it's not the fault of my program, so I'm
figuring it is caused by me not setting up something properly in alsa to
make the two streams synced up.
Any ideas of where to look?
Thanks in advance,
- Steve
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
