Re: [LAD] G++ trouble
Uwe Koloska writes: > It's standard behavior, but have only found it on There's also a bit about this in David Tribble's list of differences between C++98 and C99: http://david.tribble.com/text/cdiffs.htm#C99-const-linkage -- Adam Sampson <http://offog.org/> ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] dead audio projects worth resuming
On Wed, Feb 10, 2010 at 10:07:54PM +0100, Renato wrote: jack-rack Sorry, that one's my fault -- I've been absurdly busy with work and my thesis for the last few months, and haven't had time to look at the outstanding problems and put together a new release. If Bob or Gordon would like to take it back, or if somebody else'd like to volunteer to maintain it, I'd be happy to pass it on. The two obvious big bits of work that could be done to it are to add JACK MIDI support (which should be fairly easy), and to add support for LV2 plugins (a bit trickier). For the latter, I was wondering if it might be easier to retrofit JACK Rack's nice interface to one of the existing LV2 plugin hosts... Apologies, -- Adam Sampson a...@offog.org http://offog.org/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!
Lennart Poettering mz...@0pointer.de writes: I am Linux developer. My priority is Linux. That's nice, but most of us developers don't have the luxury of being able to forget about portability. I've spent quite a bit of effort packaging software for other free operating systems, and there's already a widespread (and largely justified) stereotype that Linux developers don't write portable code. Please don't contribute to the problem. I don't think it is worth creating a tiny mini library that I'd need to maintain and everyone depend on for just one (or two) little function call. Especially since this would be an extra dep to a lot of software. But instead you're proposing adding two dependencies (the D-Bus client library and the RealtimeKit service), and having everybody who wants to use it copy a large chunk of code into their project. I don't see how that's a simpler option than providing a library interface; it's certainly not simpler to write a configure test for. Also, the reference client should compile fine on non-Linux, however it will become a NOP and return ENOSUPP when you call it. Whether the kernel is Linux or not is completely irrelevant for a program trying to get realtime priority using your service. What matters is whether D-Bus is available. Suppose I go away and implement your realtime service for FreeBSD; because of that #ifdef, I now need to go and patch every application that's copied your code before it'll work. If the API were a library, like essentially every other API on a modern Unix-like system, then I'd only have to change the library to add support for new platforms and mechanisms, and I'd be able to support systems where asking another process to increase your privileges isn't the right way to do things. How did you come to the conclusion that dbus was AFL/GPL2-only? Can you point me to where this is claimed? It's stated clearly in the COPYING file for D-Bus: D-Bus is licensed to you under your choice of the Academic Free License version 2.1, or the GNU General Public License version 2. If that isn't their intent, it needs fixing. -- Adam Sampson a...@offog.org http://offog.org/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!
Lennart Poettering mz...@0pointer.de writes: Really, I see not much value in supporting more than one kernel. I find this statement surprising, having found that testing on multiple operating systems is an excellent way of finding subtle bugs in code. (I assume you're just talking about RealtimeKit here and not PulseAudio as a whole, since there are clear advantages to making that available to as large a userbase as possible if you want it to be widely adopted...) There is not compile time dependency on rtkit and no runtime dependency either. Yes, there is a runtime dependency on RealtimeKit -- else there would be no point in having it in the first place! If I'm building an operating system package for an application that wants realtime priority, then my package has to have an explicit dependency on RealtimeKit as well as D-Bus. Also, the client reference implementation is tiny. it just wraps two method calls. Trivial stuff. It's neither trivial nor tiny -- rtkit.c is a bit over a hundred non-comment/blank lines of code. The entirety of thread.c in libjack (which handles getting realtime priority on a variety of operating systems, among other things) is less than two hundred. This should be in a library, *not* copied-and-pasted into multiple places; that's a maintenance nightmare waiting to happen. I should be clearer here that I think the RealtimeKit approach is actually pretty sensible on Linux, and I don't have any objections to using D-Bus. I just think it's important to recognise that this approach is not appropriate for all platforms, and providing a more conventional library interface would be more convenient for programmers, more portable, and generally better software engineering practice. Then file a bug. I have done. I wasn't aware that it *was* a bug until you commented on it; I'm used to trusting packages' explicit statements in their documentation about their licenses. (Looking at license statements in headers is not sufficient; as in RealtimeKit, it's very common to have different licenses applying to different files, or dependencies on libraries which end up restricting the license of the overall package.) Thanks, -- Adam Sampson a...@offog.org http://offog.org/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [LAU] [ANN] jack_capture V0.9.32
Kjetil S. Matheussen k.s.matheus...@notam02.no writes: Sure, but I'm not familiar with the use of DESTDIR. How do you want the makefile to look? Something like this, so it supports both prefix and DESTDIR, creates the directories it needs if they don't exist, depends on the binaries being built first, and uses install rather than cp (which fails if the binary's in use): DESTDIR = prefix = /usr/local bindir = $(prefix)/bin targets = jack_capture jack_capture_gui jack_capture_gui2 install: $(targets) mkdir -p $(DESTDIR)$(bindir) install -m755 $(targets) $(DESTDIR)$(bindir) The reason for not building DESTDIR into bindir directly is that you should be able to configure and build the package with DESTDIR set, and not have the DESTDIR burnt into the binaries. This doesn't matter for jack_capture, but it's still a good habit to get into if you're rolling your own build system. I wrote a guide to making software packageable a while ago which might be of interest: http://offog.org/articles/packaging/ -- Adam Sampson a...@offog.org http://offog.org/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [EPAMP] an effect plugin API for media players: anyone interested?
Stefano D'Angelo [EMAIL PROTECTED] writes: Doesn't it sound a bit UNIX-centered? (colon separated on Windows for example?) Colons are legal in Unix paths too; if you use colon as a separator, you ought to provide some way of escaping it. -- Adam Sampson [EMAIL PROTECTED] http://offog.org/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Small Bug in Jack Rack....
Danni Coy [EMAIL PROTECTED] writes: I am posting here since the Jack-Rack Mailing list is looking decidedly unmaintained. I do keep an eye on the list, but Sourceforge's complete lack of spam filtering makes it a pain to keep the archives clean. But yes, I'd imagine anyone who's interested is probably subscribed to this list too! I have discovered a small bug in jack-rack which I at the moment cannot seem to find the source of. Which is that feedback for midi devices is sent one channel greater than it should be. Looking at the code, there was a +1 in the code that receives MIDI events but no equivalent in the code that sends them, so it was incorrectly sending 1-based channel numbers to ALSA. I've fixed it in CVS and it appears to behave correctly now; please could you give it a try and let me know if it's OK for you? If you don't want to pull the CVS version, I've put the fix here: http://offog.org/stuff/channels-fix.diff Thanks, -- Adam Sampson [EMAIL PROTECTED] http://offog.org/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAU] Re: [LAD] PHASEX-0.11.0 released
Hi,
On Wed, Aug 08, 2007 at 12:59:02AM +0300, Nedko Arnaudov wrote:
Program received signal SIGSEGV, Segmentation fault.
961 tmp_1 = part.delay_buf[2 * part.delay_read_index];
I was getting this as well. After a bit of chasing, it turned out to be
a memory corruption bug: a previous bit of code was walking off the end
of the voice array and clobbering global.bps, which resulting in
part.delay_read_index having a silly value.
Here's a fix:
--- phasex-0.11.0.orig/src/callback.c 2007-07-30 10:33:36.0 +0100
+++ phasex-0.11.0/src/callback.c2007-08-12 19:18:22.0 +0100
@@ -322,7 +322,7 @@
/* mono keeps voice 0 active */
if (patch-keymode != KEYMODE_POLY) {
voice[0].active= 1;
- voice[j].allocated = 1;
+ voice[0].allocated = 1;
}
}
It took a while to track down because both voice and global are
statically allocated; if they'd been malloced it would have shown up in
valgrind straight away.
In the process of doing this, I also noticed that the filter_key field
in voice isn't used any more.
Thanks,
--
Adam Sampson [EMAIL PROTECTED] http://offog.org/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
