-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Rui et al,
I just found that recent kernel development (merging IRQ threads into
mainline) breaks the "rtirq" setup script. Basically rtirq does nothing.
The command to get the PID
PIDS=`ps -eo pid,comm | egrep "IRQ.${IRQ}\$" | awk '{print $1}'`
(rtirq line 120) does no longer work since the IRQ process names have
changed.
I've quickly changed it to
PIDS=`ps -eo pid,comm | egrep "irq\/${IRQ}-" | awk '{print $1}'`
and it sets the priorities again, but that's not correct since it also
raises priority of other drivers on the same IRQ..
Similarly `rtirq status` returns nothing. I've checked with:
`ps -ewo pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio`
instead.
It looks like a new set of regexps for rtirq is in order ;)
This is
Linux soyuz 2.6.31-rc5-rt1.1 #1 SMP PREEMPT RT Wed Aug 5 23:06:21 CEST
2009 i686 GNU/Linux
# ps -eo pid,comm | grep -i irq
4 sirq-high/0
5 sirq-timer/0
6 sirq-net-tx/0
7 sirq-net-rx/0
8 sirq-block/0
9 sirq-tasklet/0
10 sirq-sched/0
11 sirq-hrtimer/0
12 sirq-rcu/0
149 irq/9-acpi
495 irq/14-ata_piix
496 irq/15-ata_piix
506 irq/16-yenta
526 irq/12-i8042
527 irq/1-i8042
1418 irq/8-rtc0
1428 irq/19-ehci_hcd
1446 irq/16-uhci_hcd
1447 irq/17-uhci_hcd
1450 irq/18-uhci_hcd
1452 irq/19-uhci_hcd
1544 irq/29-iwl3945
22591 sirq-high/1
22592 sirq-timer/1
22593 sirq-net-tx/1
22594 sirq-net-rx/1
22595 sirq-block/1
22596 sirq-tasklet/1
22597 sirq-sched/1
22598 sirq-hrtimer/1
22599 sirq-rcu/1
22609 irq/17-HDA Inte
22610 irq/17-ohci1394
22952 irq/16-i915@pci
22968 irq/28-eth1
Yes I'm also baffled at the high PIDs for IRQs. I hazard a guess that
those are a result of a suspend/resume cycle; and I'll check later if
the chrt settings do persist after a suspend/resume.
so long,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkp7AfMACgkQeVUk8U+VK0LBZACfUeRxyGBf5rpmMvlurTFxKRis
zk0An2QFd07wyg5wHRZXY0MJjD9dESnv
=JLI3
-----END PGP SIGNATURE-----
Patrick Shirkey:
>
> On 08/08/2009 09:57 PM, Jens M Andreasen wrote:
>> On Sat, 2009-08-08 at 16:44 +1000, Patrick Shirkey wrote:
>>
>>
>>> Here's what I have found after extensive testing with the latest dev
>>> version of pulseaudio-v0.9.16-4 and jack-0.116.1 on a 2 core amd, 4GB
>>> notebook running Fedora 11.
>>>
>>> 1. 32 bit apps will not play on a 64 bit pulseaudio easily or at all.
>>> 2. Skype, Realplayer/Helix and Flash are a pain to get working with
>>> pulseaudio if they work at all.
>>>
>>
>> These two items are related, right? Does it go away with a
>> 32bit/extended kernel?
>>
>>
>
>
> I haven't tested with a 32 bit system. I'm not sure if I will get the
> time for that. I don't think in this case it has much to do with the
> kernel. I think it is because pulse is compiled for 64 bit and the apps
> are looking for 32 bit libs.
>
Well, there's your problem. It's great that you try out new
software though, but of course then you'll get more stability
issues as well.
Hi there,
I'm trying to read midi events in a lv2 gui, but port_event() doesn't
get called when new midi events appear.
So, how do I get my midi events in the gui?
Regards and thanks in advance
Uli
The following is a copied email I previously sent to Tom Szilagyi....
On Sun, Aug 2, 2009 at 11:13 PM, Michael Fisher<mfisher31(a)gmail.com> wrote:
> Hi Tom!
>
> I just recently purchased a software item called 'The Beat Thang' .
> You can
> find it at www.beatkangz.com. I am running MacOSX Leopard. After
> installing their software and low and behold in my
> '/Library/Audio/Plug-Ins/' folder appeared a subfolder named 'LADSPA' .
> hmmmm... I should probably tell you that I mostly use linux for audio
> recording so I am familiar with ladspa, especially your plugins (very
> nice).
> Anyway. These guys are distributing binaries of the following ladspa
> plugins:
>
> * tap_chorusflanger
> * tap_echo
> * tap_echo
> * tap_pitch
> * tap_reflector
> * tap_vibrato
>
> There are other ladspa plugins too. See attached screenshot. They
> are not
> giving credit, providing source, anything really required of them from
> the
> GPL as far as I can tell. I thought you might want to know about
> this. It
> really bothers me though because I personally stand for the GPL and think
> that folks who use GPL'd software should abide by the rules.
>
> I'm pretty sure their installer is responsible for 'installing' the
> plugins
> because I can erase the LADSPA folder, then reinstall the Virtual Beat
> Thang
> and magically the LADSPA folder reappears.
>
> There is no mention for credit to you guys (Linux Audio Developers) on
> the
> Beat Kangz website either.
>
> Also, when I run their program from the terminal it outputs to stdout
> that
> indeed these ladspa plugins are being loaded. It kind of makes me wonder
> what other open source software they are using and perhaps linking
> statically to libraries and what not.
>
> -Mike
Tom Szilagyi wrote:
> Thanks for reporting this.
>
> I notice in the screenshot that there are other LADSPA plugins there
> (vinyl by Steve Harris; the CMT plugins; AFAIK all others are also
> GPL'd LADSPA).
>
> I would ask you to write a similar mail to the LAD mailing list with
> some more provocative subject ("GPL violation alert" or something like
> that) so everyone knows about this. Then together we can write a
> letter to Beat Kang asking that they abide by the GPL, or remove GPL
> from their stuff.
>
> Lets be clear: other than publicity, we don't really have a weapon
> against them. Legal action is probably out of scope for us, so in case
> they don't follow what we ask for (which is likely since I'm sure they
> knowingly violated the GPL in the first place) humiliating them as
> publicly as we can may be the best we can do.
>
> FSF or EFF may be able to help us with this (I'm sure there is at
> least one organisation dedicated to protecting the GPL, but I'm not
> sure).
>
> Tom
No problem. It's not really fair to put a 'skin' around free software,
call it your own, and then sell it. The only thing I ask is that my
name be left out of the letter that may be written to them. The reason
is, that I personally know one of the staff members at the Beat Kangz. I
just would hate to have it cause any trouble. My friend personally
doesn't have anything to do with this violation, he just works for
them. I hope that isn't a problem with you.
-Mike
Hi,
I'm just reading about the latest big thing from apple for the iPhone
and found this quite interesting.
http://iphone.akamai.com/solutions.html
"
The segmenter also creates and maintains an index file containing the
list of short media files that were created. These files are placed on a
web server.
A media player built into the iPhone OS is provided a link to the index
file, it then requests the media files in order and plays them without
any pauses or gaps between segments "
Just out of interest do we have anything like that for open source?
Doesn't seem like it would be particularly difficult to build.
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd
Arnold Krille:
> On Sunday 09 August 2009 14:12:56 Kjetil S. Matheussen wrote:
>> No, as I said, the solution is very simple: Don't install a 64 bit OS.
>> That's what's causing your problems, apparently.
>
> Helloo! Please leave the 20th century where it belongs. Nowadays 64bit are
> normal with new computers and its a terrible waste not to use them (reminds me
> of "640kB should be enough for everybody").
>
> If the combination of 64bit and 32bit-binary-only apps is broken, its the
> developers or the distributions task to fix it. And the users task to point out
> the problems and demand the fix.
>
> Looking away by only using 32bits is _not_ the solution. And please stop
> telling that "solution" to other people. We are in the 21th century after
> all...
>
Seems like you have some issues about something.? The case is that
a 32 bit OS works, while a 64 bit OS don't. So until the 64 bit
issues are fixed, using a 32 bit OS is a perfectly fine solution
to the problem. I installed a 32 bit OS because I didn't want
the kind of trouble Patrick has, and others who don't want
that kind trouble should do the same.
Dear linux-audio developers,
I have created New Project https://sourceforge.net/projects/impro-
visor/ for Impro-Visor, which is its correct name. I will populate the
source later today, as I need time to get acquainted with their
system, but I have to be off right now to another important meeting
for the afternoon and can't do it instantly. The source I will post
will be our version 4.0.
Regarding the assertion made earlier by another that I did not contact
sourceforge about the fork 'improvisor', see the forwarded message.
The fact that SF did not remove the other project immediately does not
mean they won't. Not everything happens at lightspeed. It would be a
true indication of courtesy and cooperation if the creator of that
project were simply to remove 'improvisor' as a possible source of
confusion. If not, I will consider the options regarding this action.
Forking at 3.39 would not really be a problem for me, but it seems
that there would be less stress and duplication of effort overall if
we were to proceed as I am suggesting. A year of development has been
put in between 3.39 and 4.0. (Why so long, you ask? For one thing
because of changes started by students, but not integrated, sometimes
take a long time to integrate.)
And yes, I do wish to be in control of my own project, which has been
in existence for four years. It seems reasonable to me. I DO intend to
accept contributions, however.
Thanks for your patience and understanding.
Regards,
Bob Keller
Begin forwarded message:
> From: "SourceForge.net Support" <sfnet_ops(a)corp.sourceforge.com>
> Date: July 27, 2009 9:20:36 AM PDT
> To: Bob.Keller(a)hmc.edu
> Subject: Re: Project: Improvisor has been reported as inappropriate
>
> Hello,
>
> Based on your complaint, it appears that you may wish to report a case
> of copyright infringement. SourceForge.net deals expediently with
> reports of copyright infringement.
>
> To report copyright infringement, please use our DMCA Notification
> Procedure as per
> http://sourceforge.net/apps/trac/sitelegal/wiki/DMCA%20Notification%20Proce…
>
> Regards,
> Chris Tsai
> SourceForge Support
> sfnet_ops(a)corp.sourceforge.com
>
> PS. When you submitted this report, you did not leave us any contact
> info to reply to. As such, I've taken the liberty of looking up your
> e-mail the Harvey Mudd College directory search. I trust this was not
> a problem.
>
Robert Keller
Csilla & Walt Foley Professor
Computer Science
Harvey Mudd College
Chris Cannam
> >> ... but it's probably
> >> illegal and certainly unethical to redistribute someone else's work
> >> without attribution (a basic necessity of copyright which the GPL
> >> doesn't disclaim).
The BSD license originally required attribution. The GPL people objected,
calling it the "obnoxious BSD advertising clause ... and forced this clause
removed.
So it's fair to say the GPL does NOT require attribution.
Jeff McClintock
On Friday 07 August 2009 20:10:14 you wrote:
> On Fri, Aug 7, 2009 at 5:34 PM, Raymond Martin <laseray(a)gmail.com> wrote:
> > Not at all. There is even evidence in the FSF documentation somewhere
> > exactly
> > about this point and they vehemently disagree with any attitude like
> > that. We
> > all know very well the situation of Emacs, Xemacs, and various other
> > forks.
>
> The FSF is not the law. I suggest you look up Trademark Law to realize why
> you are wrong, and why you are subject to a lawsuit for knowingly creating
> a product that is infringing on an already existing trademark(Regeristered
> or Unregeristered would make a small, but only small, difference in this
> case), and can easily be confused as such. In fact the case against
> forcing you to change it is rather strong because not only is your product
> nearly identical in name, it is nearly identical in function and can be
> easily confused with the original.
Another fool. Trademarks apply to commercial interests, the program is
non-commercial in nature. Thus it would be very difficult for anything
to be done about this for creating a free program from a free program.
Maybe you should check the fact that there is already another program called
improvisor that exists that is not Impro-Visor, it is a commercial company
that could claim trademark infringement against Impro-Visor.
So if anybody is in a problem it will be Impro-Visor first.
Raymond
