From: Conrad P. <co...@ve...> - 2007-01-11 01:04:01
Attachments:
sweep-0.9.1-jack.patch
|
---------- Forwarded message ---------- From: Alan Brenner <ala...@it...> Date: 09-Jan-2007 04:27 Subject: Sweep 0.9.1 Jack Patch To: co...@ve... Cc: le...@gr... I've updated the 0.8.2 patch by Torben Hohn to work with 0.9.1. I've tested this on Mac OS X (10.4.8 on Intel, with Fink packages for Ogg, Vorbis, and the GTK+ environment, and a stand alone build of Speex) and get audio output. I haven't tried input. I've also made the patch available at http://rit.mellon.org/Members/abrenner/sweep-0-9-1-jack-patch/view. Thanks for sweep and jack os x. |
From: Conrad P. <co...@me...> - 2007-01-11 06:39:40
Attachments:
sweep-0.9.1-jack.patch
|
---------- Forwarded message ---------- From: Alan Brenner <ala...@it...> Date: 09-Jan-2007 04:27 Subject: Sweep 0.9.1 Jack Patch To: co...@ve... Cc: le...@gr... I've updated the 0.8.2 patch by Torben Hohn to work with 0.9.1. I've tested this on Mac OS X (10.4.8 on Intel, with Fink packages for Ogg, Vorbis, and the GTK+ environment, and a stand alone build of Speex) and get audio output. I haven't tried input. I've also made the patch available at http://rit.mellon.org/Members/abrenner/sweep-0-9-1-jack-patch/view. Thanks for sweep and jack os x. |
From: pete <zen...@ze...> - 2007-01-11 06:59:58
|
On Thu, 2007-01-11 at 15:39 +0900, Conrad Parker wrote: > ---------- Forwarded message ---------- > From: Alan Brenner <ala...@it...> > Date: 09-Jan-2007 04:27 > Subject: Sweep 0.9.1 Jack Patch > To: co...@ve... > Cc: le...@gr... > > > > I've updated the 0.8.2 patch by Torben Hohn to work with 0.9.1. I've > tested this on Mac OS X (10.4.8 on Intel, with Fink packages for Ogg, > Vorbis, and the GTK+ environment, and a stand alone build of Speex) > and get audio output. I haven't tried input. I've also made the patch > available at http://rit.mellon.org/Members/abrenner/sweep-0-9-1-jack-patch/view. > duplicate post, my bad. sorry about that Conrad, what i meant to say was, *future* posts from unsubscribed addresses could be delayed, not that one, which i'd cleared. i dunno though, you really should think about upgrading your mind reading abilities.. :P i'll get in touch with Alan Brenner WRT the jack branch and check over the patch to see if there are any substantial differences. while i'm here, i've finally gotten around to sorting out a drive to install fedora core and open suse. this means i can look into a couple of bugs reports that i wanted to fix or close before putting out 0.9.2. so the *impending* release might actually be, y'know, "impending" again. :) cheers, pete. |
From: <rad...@ko...> - 2007-01-11 23:11:17
|
On 2007-01-11, at 02:03, Conrad Parker wrote: > ---------- Forwarded message ---------- > From: Alan Brenner <ala...@it...> > Date: 09-Jan-2007 04:27 > Subject: Sweep 0.9.1 Jack Patch > To: co...@ve... > Cc: le...@gr... > > > > I've updated the 0.8.2 patch by Torben Hohn to work with 0.9.1. I've > tested this on Mac OS X (10.4.8 on Intel, with Fink packages for Ogg, > Vorbis, and the GTK+ environment, and a stand alone build of Speex) > and get audio output. I haven't tried input. I've also made the patch > available at http://rit.mellon.org/Members/abrenner/sweep-0-9-1-=20 > jack-patch/view. > > Thanks for sweep and jack os x. > <sweep-0.9.1-jack.patch> > Low quality patch - sorry. There are changes in configure. But what about native CoreAudio support? This patch implements (am i right???) simple driver/library callback =20 support as required by CoreAudio, so when we've got it in mainstream repo i'll start coding CoreAudio =20 support - as volunteer :) (bcause halve of my sweep devel is done on mac) bye --=20 Rados=C5=82aw Korzeniewski rad...@ko... |
From: pete <zen...@ze...> - 2007-01-12 01:33:03
|
On Fri, 2007-01-12 at 00:11 +0100, Rados=C5=82aw Korzeniewski wrote: > > I've updated the 0.8.2 patch by Torben Hohn to work with 0.9.1. I've > > tested this on Mac OS X (10.4.8 on Intel, with Fink packages for Ogg, > > Vorbis, and the GTK+ environment, and a stand alone build of Speex) > > and get audio output. I haven't tried input. I've also made the patch > > available at http://rit.mellon.org/Members/abrenner/sweep-0-9-1-=20 > > jack-patch/view. > > > > Thanks for sweep and jack os x. > > <sweep-0.9.1-jack.patch> > > >=20 > Low quality patch - sorry. There are changes in configure. looking at it, it's just an update of Torben's jack playback patch which has already been merged into the jack branch. i don't see any new or significantly altered functionality.=20 > But what about native CoreAudio support? > This patch implements (am i right???) simple driver/library callback =20 > support as required by CoreAudio, so sort of. rather than extending the existing driver api to support pull (rather than the current push) operation, the jack patch oversteps the scope of the driver api and reaches directly into the playback code (play.c). this is because it's not possible using only the current driver api. as such, the process callback is neither abstracted so as to be generic (applicable to other audio systems), nor is it part of the driver api. it's a stop gap solution pending a reworking of the driver api.=20 so, i don't recommend using it as a basis to write other callback based drivers.=20 if you could come up with working modifications to the driver api that makes generic provision for callback based audio backends then i'm about ready to put them in before we release 1.0 (given that the release of 1.0 seems about as far away now as it's been since the gtk2 port was merged) i know much more about sweeps internal operation than i used to but i'm not confident enough to try this myself yet.=20 any thoughts? cheers, pete. |
From: <rad...@ko...> - 2007-01-12 12:23:49
|
MjAwNy8xLzEyLCBwZXRlIDx6ZW5hZHNsNjI1MkB6ZW4uY28udWs+Ogo+ID4gTG93IHF1YWxpdHkg cGF0Y2ggLSBzb3JyeS4gVGhlcmUgYXJlIGNoYW5nZXMgaW4gY29uZmlndXJlLgo+Cj4gbG9va2lu ZyBhdCBpdCwgaXQncyBqdXN0IGFuIHVwZGF0ZSBvZiBUb3JiZW4ncyBqYWNrIHBsYXliYWNrIHBh dGNoIHdoaWNoCj4gaGFzIGFscmVhZHkgYmVlbiBtZXJnZWQgaW50byB0aGUgamFjayBicmFuY2gu IGkgZG9uJ3Qgc2VlIGFueSBuZXcKPiBvciBzaWduaWZpY2FudGx5IGFsdGVyZWQgZnVuY3Rpb25h bGl0eS4KCkRvZXMgaXQgbWVhbnMgdGhhdCBzd2VlcC1qYWNrLXRlc3RpbmcgYnJhbmNoIGJlY29t ZSB1cGRhdGVkPwoKPiA+IEJ1dCB3aGF0IGFib3V0IG5hdGl2ZSBDb3JlQXVkaW8gc3VwcG9ydD8K PiA+IFRoaXMgcGF0Y2ggaW1wbGVtZW50cyAoYW0gaSByaWdodD8/Pykgc2ltcGxlIGRyaXZlci9s aWJyYXJ5IGNhbGxiYWNrCj4gPiBzdXBwb3J0IGFzIHJlcXVpcmVkIGJ5IENvcmVBdWRpbywgc28K Pgo+IHNvcnQgb2YuCj4gcmF0aGVyIHRoYW4gZXh0ZW5kaW5nIHRoZSBleGlzdGluZyBkcml2ZXIg YXBpIHRvIHN1cHBvcnQgcHVsbCAocmF0aGVyCj4gdGhhbiB0aGUgY3VycmVudCBwdXNoKSBvcGVy YXRpb24sIHRoZSBqYWNrIHBhdGNoIG92ZXJzdGVwcyB0aGUgc2NvcGUgb2YKPiB0aGUgZHJpdmVy IGFwaSBhbmQgcmVhY2hlcyBkaXJlY3RseSBpbnRvIHRoZSBwbGF5YmFjayBjb2RlIChwbGF5LmMp Lgo+IHRoaXMgaXMgYmVjYXVzZSBpdCdzIG5vdCBwb3NzaWJsZSB1c2luZyBvbmx5IHRoZSBjdXJy ZW50IGRyaXZlciBhcGkuCgpPSywgaSBkaWRuJ3QgbG9vayB0b28gbXVjaCBhdCB0aGlzIGNvZGUu Cgo+IGFzIHN1Y2gsIHRoZSBwcm9jZXNzIGNhbGxiYWNrIGlzIG5laXRoZXIgYWJzdHJhY3RlZCBz byBhcyB0byBiZSBnZW5lcmljCj4gKGFwcGxpY2FibGUgdG8gb3RoZXIgYXVkaW8gc3lzdGVtcyks IG5vciBpcyBpdCBwYXJ0IG9mIHRoZSBkcml2ZXIgYXBpLgo+IGl0J3MgYSBzdG9wIGdhcCBzb2x1 dGlvbiBwZW5kaW5nIGEgcmV3b3JraW5nIG9mIHRoZSBkcml2ZXIgYXBpLgo+IHNvLCBpIGRvbid0 IHJlY29tbWVuZCB1c2luZyBpdCBhcyBhIGJhc2lzIHRvIHdyaXRlIG90aGVyIGNhbGxiYWNrIGJh c2VkCj4gZHJpdmVycy4KPgo+IGlmIHlvdSBjb3VsZCBjb21lIHVwIHdpdGggd29ya2luZyBtb2Rp ZmljYXRpb25zIHRvIHRoZSBkcml2ZXIgYXBpIHRoYXQKPiBtYWtlcyBnZW5lcmljIHByb3Zpc2lv biBmb3IgY2FsbGJhY2sgYmFzZWQgYXVkaW8gYmFja2VuZHMgdGhlbiBpJ20gYWJvdXQKPiByZWFk eSB0byBwdXQgdGhlbSBpbiBiZWZvcmUgd2UgcmVsZWFzZSAxLjAgKGdpdmVuIHRoYXQgdGhlIHJl bGVhc2Ugb2YKPiAxLjAgc2VlbXMgYWJvdXQgYXMgZmFyIGF3YXkgbm93IGFzIGl0J3MgYmVlbiBz aW5jZSB0aGUgZ3RrMiBwb3J0IHdhcwo+IG1lcmdlZCkKCkJ1dCB3aGF0IGFib3V0IGxpYnJlbWl4 LCB3aGljaCBDb25yYWQgaXMgd29ya2luZyBvbj8KRG9lcyBpdCBhZmZlY3RzIGF1ZGlvIGRyaXZl ciBhcGk/IEhvdyBtdWNoPwoKSSB3YXMgd3JpdGluZyBpbiBGZWF0dXJlIFJlcXVlc3RzL1RPRE8g dGhlIG5lZWQgb2YgbmV3IGF1ZGlvIGRyaXZlcgphcGkvZnJhbWV3b3JrLiBUaGlzIGlzIGEgY29y ZSBmb3VuZGF0aW9uIGZvciB0aGlzIGtpbmQgb2YgYXBwbGljYXRpb25zCmxpa2Ugc3dlZXAuCgo+ IGkga25vdyBtdWNoIG1vcmUgYWJvdXQgc3dlZXBzIGludGVybmFsIG9wZXJhdGlvbiB0aGFuIGkg dXNlZCB0byBidXQKPiBpJ20gbm90IGNvbmZpZGVudCBlbm91Z2ggdG8gdHJ5IHRoaXMgbXlzZWxm IHlldC4KPgo+IGFueSB0aG91Z2h0cz8KCldlIHNob3VsZCBzdGFydCBmcm9tIGNvbGxlY3Rpbmcg bmVlZHMgYW5kIGRpc2N1c3MgYWJvdXQgcG9zc2liaWxpdGllcywKZmluYWxseSB3ZSBzaG91bGQg Y2hvb3NlIGEgYmVzdCB3YXkgYW5kIGltcGxlbWVudCBpdC4KRGF5IGJ5IGRheSBpIGtub3cgbW9y ZSBhYm91dCBzd2VlcCBpbnRlcm5hbHMgYW5kIGkgY2FuIGJlIG9uZSBvZiB0aGUKZmlyc3Qgdm9s dW50ZWVyIDopCgpjaGVlcnMKCi0tIApSYWRvc8WCYXcgS29yemVuaWV3c2tpCnJhZG9zbGF3QGtv cnplbmlld3NraS5uZXQK |
From: pete <zen...@ze...> - 2007-01-13 08:23:46
|
On Fri, 2007-01-12 at 13:23 +0100, Rados=C5=82aw Korzeniewski wrote:=20 > 2007/1/12, pete <zen...@ze...>: > > > Low quality patch - sorry. There are changes in configure. > > > > looking at it, it's just an update of Torben's jack playback patch whic= h > > has already been merged into the jack branch. i don't see any new > > or significantly altered functionality. >=20 > Does it means that sweep-jack-testing branch become updated? no. i guess the patch author wasn't aware that Torben's jack patch had already been updated for 0.9.1 and put into a branch. it duplicates=20 what has already been done. > > if you could come up with working modifications to the driver api that > > makes generic provision for callback based audio backends then i'm abou= t > > ready to put them in before we release 1.0 (given that the release of > > 1.0 seems about as far away now as it's been since the gtk2 port was > > merged) >=20 > But what about libremix, which Conrad is working on? > Does it affects audio driver api? How much? good question. i was looking at the remix api recently and my first estimation was that it probably won't affect the drivers much, if at all. the sample display, plugins, playback and recording are another matter and will need significant changes in order to work with remix. (with remix replacing some of it, naturally) > I was writing in Feature Requests/TODO the need of new audio driver > api/framework. This is a core foundation for this kind of applications > like sweep. i don't think we should rewrite the whole thing unless there's some clear reason to do so. the current push model works fine. if we could add a minimally invasive extension that provides a pull model and at the very least, run time selectable (if not modular) drivers,=20 i'd be very happy with that. > We should start from collecting needs and discuss about possibilities, > finally we should choose a best way and implement it. that would be the best way to proceed but Conrad isn't working on sweep at the moment and i doubt that i know more about how to proceed than you do so it might be a one sided discussion. if you need input from Conrad then we should wait until he's back working on sweep. you are doing plenty of useful work on sweep anyway so it's not as if we aren't moving forwards in other areas. :) cheers, pete. |
From: <rad...@ko...> - 2007-01-16 20:22:31
|
On 2007-01-13, at 09:22, pete wrote: >> But what about libremix, which Conrad is working on? >> Does it affects audio driver api? How much? > > good question. i was looking at the remix api recently and my first > estimation was that it probably won't affect the drivers much, if at > all. the sample display, plugins, playback and recording are another > matter and will need significant changes in order to work with remix. > (with remix replacing some of it, naturally) I didn't look too much at libremix, so does it change sample memory =20 model? or does it allow to change it? Current sample memory model (sounddata) is very inefficient and limited. > >> I was writing in Feature Requests/TODO the need of new audio driver >> api/framework. This is a core foundation for this kind of =20 >> applications >> like sweep. > > i don't think we should rewrite the whole thing unless there's some > clear reason to do so. the current push model works fine. if we could > add a minimally invasive extension that provides a pull model and > at the very least, run time selectable (if not modular) drivers, > i'd be very happy with that. This is a question: is it better to extend current driver model or to =20= redesign/rewrite it? I think that modular driver framework which will support both pull =20 and push driver model should be carefully designed. We can use current driver code of course. > > you are doing plenty of useful work on sweep anyway so it's not as if > we aren't moving forwards in other areas. :) You are right, and i'm focusing now on features which doesn't change =20 sweep internals and are relatively simple to merge it into main trunk. cheers --=20 Rados=C5=82aw Korzeniewski rad...@ko... |
From: pete <zen...@ze...> - 2007-01-29 09:17:05
|
On Tue, 2007-01-16 at 21:22 +0100, Rados=C5=82aw Korzeniewski wrote: > On 2007-01-13, at 09:22, pete wrote: > >> But what about libremix, which Conrad is working on? > >> Does it affects audio driver api? How much? > > > > good question. i was looking at the remix api recently and my first > > estimation was that it probably won't affect the drivers much, if at > > all. the sample display, plugins, playback and recording are another > > matter and will need significant changes in order to work with remix. > > (with remix replacing some of it, naturally) >=20 > I didn't look too much at libremix, so does it change sample memory =20 > model? or does it allow to change it? > Current sample memory model (sounddata) is very inefficient and limited. remix effectively streams to and from the disk. so i expect sounddata will be removed. you should check the remix source for implementation details. also, here's a paper that Conrad wrote about libremix (or axel as it was then called) that provides a helpful conceptual overview. http://www.metadecks.org/software/axel/doc/inside_sweep.html > > > >> I was writing in Feature Requests/TODO the need of new audio driver > >> api/framework. This is a core foundation for this kind of =20 > >> applications > >> like sweep. > > > > i don't think we should rewrite the whole thing unless there's some > > clear reason to do so. the current push model works fine. if we could > > add a minimally invasive extension that provides a pull model and > > at the very least, run time selectable (if not modular) drivers, > > i'd be very happy with that. > This is a question: is it better to extend current driver model or to =20 > redesign/rewrite it? technically? i don't know.=20 > I think that modular driver framework which will support both pull =20 > and push driver model should be carefully designed. > We can use current driver code of course. ok. that takes time and the kind of cogent coordination that i can't provide so lets wait until Conrad picks up sweep again before getting into it. cheers, pete. |