headers
R. Dresens | 1 Apr 2008 03:48
Picon

Detecting new alsa sequencer clients (with some event loop) so that i can subscribe them


Hello,

I'm currently writing an application that will be able to 'auto
subscribe' itself to a certain sequencer client when that client
becomes available to the system. I want (for example) to be able to 
plug in a USB MIDI interface, and when I do that then my application
detects this and does a subscription on it, just like aconnect would
do.

A possible solution is polling; every second or so, i could generate a
list of clients with snd_seq_query_next_client and look for a certain
client name (libpcre comes to mind here;), but I was wondering if there
is a better solution? ..in other words, is it possible to get such
events from the system in a similar way like one would receive regular
MIDI events?

http://www.alsa-project.org/alsa-doc/alsa-lib/structsnd__seq__event.html
list all the events; an interesting one could be snd_seq_connect_t
for monitoring connections on my own ports, but that's not what I'm
looking for. I can't seem to find an event related to this
functionality. Is there something what I'm currently overlooking?

Such functionality may be usefull for GUI versions of aconnect. I
looked in the source of qjackctl (it has an alsa patchbay), but I
haven't found nothing usefull yet since it seems to me that this
software also does polling/refresh on a certain interval.

Has anyone a usefull tip for me?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Clemens Ladisch | 1 Apr 2008 09:01
Picon
Gravatar

Re: Detecting new alsa sequencer clients (with some event loop) so that i can subscribe them

R. Dresens wrote:
> I'm currently writing an application that will be able to 'auto
> subscribe' itself to a certain sequencer client when that client
> becomes available to the system. I want (for example) to be able to
> plug in a USB MIDI interface, and when I do that then my application
> detects this and does a subscription on it, just like aconnect would
> do.
>
> A possible solution is polling; every second or so, i could generate a
> list of clients with snd_seq_query_next_client and look for a certain
> client name (libpcre comes to mind here;), but I was wondering if there
> is a better solution? ..in other words, is it possible to get such
> events from the system in a similar way like one would receive regular
> MIDI events?

Subscribe to SND_SEQ_CLIENT_SYSTEM:SND_SEQ_PORT_SYSTEM_ANNOUNCE.
Try "aseqdump -p 0:1" to see what events you get.

HTH
Clemens
Permalink | Reply | 1 comment |
headers
Vova Barinov | 1 Apr 2008 22:08
Picon

Re: [Fwd: Re: Davinci ASoC support (patch)]

lokowich wrote:
>
>
> Vova Barinov wrote:
>> Mark Brown wrote:
>>   
>>> On Fri, Mar 28, 2008 at 09:27:04AM -0500, lokowich wrote:
>>>
>>>   
>>>     
>>>> Forwarded from davinci-linux-open-source list:
>>>>     
>>>>       
>>> CCing in Vladimir Barinov who contributed the DaVinci support.
>>>
>>>   
>>>     
>>>> I've built this ASoC patch into my DaVinci git kernel (thanks for the 
>>>> SENSORS tip), and can use aplay and speaker-test, but no sound.  Figured 
>>>> it may be a mixer/volume control issue, but the alsamixer is unable to 
>>>> open for a failed ioctl on USBDEVFS_IOCTL.  Not sure why there is a USB 
>>>> dependency.  Noted that there is no /sys/class/sound/mixer in my sysfs.  
>>>> Any ideas?
>>>>     
>>>>       
>> How do you figure out that you can play sound?
>> Also what platform do you use - is it Davinci-EVM? what line output do 
>> you use to hear the sound?
>> Please, post your dmesg log and cat /proc/interrupts too.
>>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Cliff Cai | 1 Apr 2008 16:17
Picon
Favicon

How to reduce delay between playback and capture for echo canceller


Hi all,

  I'm playing a linphone based VOIP demo board these days,the board can connect different soundcard
daughter board 
as playback and capture devices through  I2S or AC97.Then I experience a bad echo on my PC(using liphone and
headset) when 
talk with the board (with speaker and MIC on board).So I enable the echo canceller (based on speex) for it.
One of my sound card (connected by I2S) works pretty well,but the other one (connected by AC97) doesn't work.
Through the diagnostic tool provided by speex I find that the ac97 one has a big delay between played
signal(reference signal)
and captured signal.Just the delay make echo canceller don't work as expectation.So I think the driver for
the AC97 soundcard
need some improvement to reduce the delay.

Has anyone a usefull direction for me? Thanks in advance,Best Regards

Cliff Cai

 

 

_________________________________________________________________
MSN 中文网，最新时尚生活资讯，白领聚集门户。
http://cn.msn.com
_______________________________________________
Alsa-devel mailing list
Alsa-devel <at> alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
(Continue reading)

Permalink | Reply | 0 comments |
headers
R. Dresens | 1 Apr 2008 23:24
Picon

Re: Detecting new alsa sequencer clients (with some event loop) so that i can subscribe them

On Tue, 01 Apr 2008 09:01:50 +0200
Clemens Ladisch <clemens <at> ladisch.de> wrote:

> > A possible solution is polling; every second or so, i could
> > generate a list of clients with snd_seq_query_next_client and
> > look for a certain client name (libpcre comes to mind here;), but
> > I was wondering if there is a better solution? ..in other words, is
> > it possible to get such events from the system in a similar way
> > like one would receive regular  MIDI events?
> 
> Subscribe to SND_SEQ_CLIENT_SYSTEM:SND_SEQ_PORT_SYSTEM_ANNOUNCE.
> Try "aseqdump -p 0:1" to see what events you get.

Yes, that did the trick: this is exactly what I'm looking for.

Thanks for your help!

Greetings,

Raymond Dresens.
Permalink | Reply | 0 comments |
headers
Risto Suominen | 1 Apr 2008 20:01
Picon

Re: snd-powermac

I'm experiencing an unpleasant situation when trying to test my
patches (for ALSA 1.0.16) with kernel 2.6.15. The snd-powermac module
cannot be unloaded. Or can, but after that the computer stops
responding before it can be shut down. A visible symptom of the
problem is two kernel messages:

Trying to free free IRQ17
Trying to free free IRQ9

The oddest is that the third, IRQ8, that is freed between the other
two, is ok. They are allocated and freed in the same order and manner
in alsa-kernel/ppc/pmac.c.

I had to do following patches to compile and load the module, maybe
the first one causes this, the second one is just to disable the
TOONIE case as the chip is moved out of the driver:

--- alsa-kernel/ppc/pmac.h.orig 2008-02-05 11:23:24.000000000 +0200
+++ alsa-kernel/ppc/pmac.h      2008-03-31 23:45:36.000000000 +0300
 <at>  <at>  -207,4 +207,11  <at>  <at> 

 int snd_pmac_add_automute(struct snd_pmac *chip);

+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16)
+#define of_device_is_compatible(dev, s) device_is_compatible(dev, s)
+#define input_get_drvdata(dev) (dev->private)
+#define i2c_smbus_write_i2c_block_data(client, cmd, len, vals) \
+       i2c_smbus_write_block_data(client, cmd, len, vals)
+#endif
+
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tyson Whitehead | 1 Apr 2008 20:07
Picon

Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

Bob Tracy wrote:
> rct wrote:
>> Rene Herman wrote:
>>> Okay, and applying the attached just makes your sound completely dead in the 
>>> water?
>>> (patch to remove es1888_init from a Miata build omitted)
>> I'll try a build with the old OSS "sb" driver, and if that works ok, we
>> may be able to do away with es1888_init() on the Miata.  Tyson -- I
>> think you have a Miata if I'm remembering correctly: can you confirm
>> these observations?
> 
> Quick followup: OSS "sb" driver works fine without es1888_init().
> 

Okay.  I finally got everything tested on my Miata.  Unless I missed 
something, the es1888_init routine only gets compiled in with 
CONFIG_ALPHA_MIATA.  As I've been using the debian generic kernel (i.e., 
CONFIG_ALPHA_GENERIC), I have never relied on this routine for anything.

I did discover, however, when I compiled my own kernel (2.6.25-rc5) with 
CONFIG_ALPHA_MIATA, things stopped working.  Specifically, I no longer 
got any interupts (with or without the es1888_init patch and with or 
without the alternative es188xx interupt patch) associated with either 
the builtin sound card (es1888) or the IDE controller (CMD646).

With CONFIG_ALPHA_GENERIC I only get one interupt with the es18xx driver 
unless I applied to "alternative interupt" handling code.  Further, 
sometime between 2.6.14 and 2.6.16, mpg321 (using the alsa driver) 
started generating "Bad page state in process 'mpg321' ... Trying to fix 
it up, but a reboot is needed" kernel messages.
(Continue reading)

Permalink | Reply | 1633 comments |
headers
Rene Herman | 1 Apr 2008 20:34
Picon

Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

On 01-04-08 20:07, Tyson Whitehead wrote:

> Hope this helps.

Not really no. A lot of data has come in by now and I'll try to sort through 
it trying to distill some sense out of it all later but throwing my hands up 
in the air and finding some older Alpha system to urinate on sounds about as 
good an idea as any at the moment.

Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 5 comments |
headers
Rene Herman | 1 Apr 2008 20:29
Picon

Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

On 01-04-08 20:07, Tyson Whitehead wrote:

> Hope this helps.

Not really no. A lot of data has come in by now and I'll try to sort through 
it trying to distill some sense out of it all later but throwing my hands up 
in the air and finding some older Alpha system to urinate on sounds about as 
good an idea as any at the moment.

Rene.
Permalink | Reply | 0 comments |
headers
Rene Herman | 1 Apr 2008 20:31
Picon

Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

On 01-04-08 20:07, Tyson Whitehead wrote:

> Hope this helps.

Not really no. A lot of data has come in by now and I'll try to sort through 
it trying to distill some sense out of it all later but throwing my hands up 
in the air and finding some older Alpha system to urinate on sounds about as 
good an idea as any at the moment.

Rene.
Permalink | Reply | 0 comments |

Gmane