On Fri, 2005-03-18 at 08:24 -0700, Hans Fugal wrote:
>
> As I understand it, alsa can be asynchronous but it requires using SIGIO
> which doesn't excite me. So I'd have to create another thread that
> selects and fills a ringbuffer.
>
Ehrm ... How will putting SIGIO in another thread improve yo
On Fri, 2005-03-18 at 17:53 +0100, Tim Orford wrote:
[snip]
> but presumably it doesnt support jack-transport..?
>
I am possibly ignorant, but here goes ..
Do jack-transport support SMPTE
Do jack-transport support MIDI song pointer
(guessing yes to above)
Then ... What is it that jack-tran
On Fri, 2005-03-18 at 15:51 +, Chris Cannam wrote:
> On Friday 18 Mar 2005 15:40, Ivica Ico Bukvic wrote:
> > 2) The other option is obviously to use alsa-sequencer API but in that case
> > is there a way to simply convert the stream of received MIDI data into raw
> > midi format so that I can
Thanks Paul,
I look into that particular file.
Best wishes,
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-audio-dev-
> [EMAIL PROTECTED] On Behalf Of Paul Davis
> Sent: Friday, March 18, 20
Thanks all for your replies. I tried messing with the snd_midi_event_* stuff
but none provided proper data as when I tried accessing the struct with
8-bit data I got number like 15360 or something like that. I am sure that I
am misreading something or simply doing something incorrectly, pointers to
On Fri, Mar 18, 2005 at 08:24:01AM -0700, Hans Fugal wrote:
> I'm writing an application that will use alsa in the common case, but be
> jack-capable. I'm faced with the following design question: Do I wrap
> the jack part to emulate the read/write of alsa, or do I wrap the alsa
> part to emulate t
On Fri, Mar 18, 2005 at 10:47:55AM -0500, Paul Davis wrote:
> [...] bio2jack. it adds latency to the app that uses it, but
> it does work.
but presumably it doesnt support jack-transport..?
--
Tim Orford
On Fri, 18 Mar 2005 at 10:47 -0500, Paul Davis wrote:
> if your app is supposed to be a realtime audio app, then a callback
> driven model is almost demonstrably more correct. SIGIO is not
> appropriate for this.
For context, the app is a softphone. All linux softphones stink in all
ways, plus no
On Fri, 2005-18-03 at 08:24 -0700, Hans Fugal wrote:
> I'm writing an application that will use alsa in the common case, but be
> jack-capable. I'm faced with the following design question: Do I wrap
> the jack part to emulate the read/write of alsa, or do I wrap the alsa
> part to emulate the call
Am Freitag, 18. März 2005 16:47 schrieb Paul Davis:
> also, there is already a library that can convert a
> blocking read/write app into a JACK client. xmms-jack uses
> it, i regret that i forget its name. there is a link on the
> JACK site on the apps page. Might be bio2jack. it adds
> latency to
On Friday 18 Mar 2005 15:40, Ivica Ico Bukvic wrote:
> 2) The other option is obviously to use alsa-sequencer API but in that case
> is there a way to simply convert the stream of received MIDI data into raw
> midi format so that I can use my built-in raw MIDI parsing engine for
> parsing the messa
>I did a bit of hacking on my app trying to make it alsa sequencer compatible
>but did not want to do too much changing in terms of how it deals with raw
>MIDI data. From looking at the API reference it seems that I have 2 choices:
libmidi++ in the ardour source tree has what you need. at least as
>I'm writing an application that will use alsa in the common case, but be
>jack-capable. I'm faced with the following design question: Do I wrap
>the jack part to emulate the read/write of alsa, or do I wrap the alsa
>part to emulate the callback style of jack? In other words, do I push or
>pull fr
Hi all,
I did a bit of hacking on my app trying to make it alsa sequencer compatible
but did not want to do too much changing in terms of how it deals with raw
MIDI data. From looking at the API reference it seems that I have 2 choices:
1) Use raw midi option and specify "virtual" name which make
I'm writing an application that will use alsa in the common case, but be
jack-capable. I'm faced with the following design question: Do I wrap
the jack part to emulate the read/write of alsa, or do I wrap the alsa
part to emulate the callback style of jack? In other words, do I push or
pull from th
So I messed around for a little bit and found something that kinda
works. I was routing alsa-player in ardour (all this with jack of
course), my sound card input also into ardour, mixing the two channels
in ardour, and outputting the master out of ardour into oddcast, which
then sent to icecast
I've been trying to get oddcast to work the past couple days, but keep
running into this problem
ringbuffer full, tried to write 4096, but wrote 0
its usually in response to something distracting the processor for a
second, like dragging a window across the screen. Have tried on a 1.5ghz
ppc pr
Steve, this is from ardour-users. I know the problem too: SC1 to SC4
more or less always stop working after some twiddling. Meaning the
audio gets through only when SC* are bypassed or removed. I suppose you
don't know the problem but maybe you can tell me what exactly you need
to know to debug
18 matches
Mail list logo
