headers
Robert Bebop | 3 May 2012 12:35
Picon

Callback from C

Hi all,

Is it actually possible to callback from C with SBCL. According to the 
manual it's tricky but the CFFI manual claims that it's possible on some 
platforms with SBCL.

I am a musician and enjoy messing around with audio DSP. I currently use 
SBCL on a GNU/Linux platform and have written a C wrapper for the JACK 
audio server. I am getting pretty good real-time performance with the 
current blocking method I am using (about 10 -15 ms latency) but it 
should improve if I can get the server to callback into LISP.

I have written the FFI interface using SBCL's interface but if CFFI 
works I will recode to use it.

Another question I have is whether there could be some unpleasant side 
effects of having a real-time thread callback into LISP.

Thanks,

Robert.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Permalink | Reply |
headers
Kalyanov Dmitry | 3 May 2012 12:47
Picon
Gravatar

Re: Callback from C

0On Thu, 2012-05-03 at 12:35 +0200, Robert Bebop wrote:
> Hi all,
> 
> Is it actually possible to callback from C with SBCL. According to the 
> manual it's tricky but the CFFI manual claims that it's possible on some 
> platforms with SBCL.
> 
> I am a musician and enjoy messing around with audio DSP. I currently use 
> SBCL on a GNU/Linux platform and have written a C wrapper for the JACK 
> audio server. I am getting pretty good real-time performance with the 
> current blocking method I am using (about 10 -15 ms latency) but it 
> should improve if I can get the server to callback into LISP.
> 
> I have written the FFI interface using SBCL's interface but if CFFI 
> works I will recode to use it.
> 
> Another question I have is whether there could be some unpleasant side 
> effects of having a real-time thread callback into LISP.
> 
> Thanks,
> 
> Robert.

It is possible to call back from C to SBCL (with either SBCL's FFI or
with CFFI). The big caveat is that callback invocation has to happen on
a Lisp thread (an initial Lisp thread or thread created with
sb-thread:create-thread).

As far as I know, many audio APIs invoke callbacks in their own threads
which conflicts with the requirement of invoking callback in Lisp
(Continue reading)

Permalink | Reply |
headers
Robert Bebop | 3 May 2012 13:57
Picon

Re: Callback from C

El 03/05/12 12:47, Kalyanov Dmitry escribió:
> 0On Thu, 2012-05-03 at 12:35 +0200, Robert Bebop wrote:
>> Hi all,
>>
>> Is it actually possible to callback from C with SBCL. According to the
>> manual it's tricky but the CFFI manual claims that it's possible on some
>> platforms with SBCL.
>>
>> I am a musician and enjoy messing around with audio DSP. I currently use
>> SBCL on a GNU/Linux platform and have written a C wrapper for the JACK
>> audio server. I am getting pretty good real-time performance with the
>> current blocking method I am using (about 10 -15 ms latency) but it
>> should improve if I can get the server to callback into LISP.
>>
>> I have written the FFI interface using SBCL's interface but if CFFI
>> works I will recode to use it.
>>
>> Another question I have is whether there could be some unpleasant side
>> effects of having a real-time thread callback into LISP.
>>
>> Thanks,
>>
>> Robert.
> It is possible to call back from C to SBCL (with either SBCL's FFI or
> with CFFI). The big caveat is that callback invocation has to happen on
> a Lisp thread (an initial Lisp thread or thread created with
> sb-thread:create-thread).
>
> As far as I know, many audio APIs invoke callbacks in their own threads
> which conflicts with the requirement of invoking callback in Lisp
(Continue reading)

Permalink | Reply |
headers
Leslie P. Polzer | 3 May 2012 14:18
Picon

Re: Callback from C

On Thu, May 03, 2012 at 01:57:19PM +0200, Robert Bebop wrote:
> Signaling a condition sounds like the best way to go although I'm not 
> sure as to how to signal a Lisp condition from C and can't see anything 
> in the manual about it?

He was talking about condition *variables*. They help with thread
coordination and don't really have anything to do with Common Lisp
conditions.

  Leslie

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Permalink | Reply |
headers
Robert Bebop | 3 May 2012 15:06
Picon

Re: Callback from C

El 03/05/12 14:18, Leslie P. Polzer escribió:
> On Thu, May 03, 2012 at 01:57:19PM +0200, Robert Bebop wrote:
>> Signaling a condition sounds like the best way to go although I'm not
>> sure as to how to signal a Lisp condition from C and can't see anything
>> in the manual about it?
> He was talking about condition *variables*. They help with thread
> coordination and don't really have anything to do with Common Lisp
> conditions.
>
>    Leslie
Ok, thanks Leslie, I misunderstood.

That is actually what I'm doing now with pthread conditions, I thought 
Kalyanov was suggesting that a LISP condition would be a good way to go. 
It seems that the limitations on performance depend on the GC and lack 
of priority scheduling on the sb-thread. I guess I'll have to wait until 
SBCL develops some kind of scheduling mechanism for different 
sb-threads. I am too nervous about running SBCL top-level in hard real-time.

Cheers.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Permalink | Reply |

Gmane