Re: [linux-audio-dev] silent for a while

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] silent for a while
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Jun 25 2001 - 06:13:37 EEST


>I've been poking the code, it seems to get into a state where the engine
>will freeze somewhere before audioengine_add_port_segment gets called,
>which means that the engine struct isn't set up correctly and bad things
>happen when a client tries to connect.
>
>After trying to debug it for a half hour or so alsa started spamming into
>/var/log/messages and I had to do a soft reboot.

Any news?

>> ideas on how to have clients get access to the list of port
>> connections are also very welcome.
>
>Thinking about this and the new ports problem. No inspiration yet.

The answer became very clear while I was travelling.

When two ports are connected, the connectivity of the graph is changed
(potentially). Instead of just sending the client the "reorder" event
that tells it to reconnect to a new event notification channel (e.g. a
named pipe), you also send it the name of the port that was connected
(or disconnected). Then, the client-side library can maintain its own
client-side list of connections, and then
audioengine_get_port_buffer() can perform the sort of magic tricks
we've spoken of. There are several structures like this which can
really be split up (and very slightly duplicated) across the client
(in- or out-of-process).

This works because ultimately, a connection is just a pair of port
ID's, and a port ID points to a location in shared memory which is
valid for all clients. Hence, we can do the mixing of several inbound
connections from the relevant client since it will know all the ports
its input port is connected to and can access their buffers.

I also want to measure the speed of SysV semaphores for the graph. It
occurs to me that since they never imply data transfer, and since they
don't involve the file system in any way, they may be faster than
named pipes to drive the out-of-process graph or subgraphs.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jun 25 2001 - 06:15:35 EEST