Linux-audio-dev November 2002

linux-audio-dev@lists.linuxaudio.org

87 participants
85 discussions

by engr bankole

FROM:ENGR BANKOLE ADEKANMI, PETROLEUM AND PROJECT DIVISION FALOMO, LAGOS-NIGERIA This letter is not intended to cause any embarrassment in whatever form,rather is compelled to contact your esteemed self, following the knowledge of your high reputes and trusts worthiness. Firstly, I must solicit your confidentiality; this is by the virtue as Being utterly confidential and top secret though I know that a Transaction Of this magnitude will make anyone apprehensive and worried, but I Am assuring you that all will be well at the end of the day. A bold step Taken shall not be regretted I assure you. I am Engr Bankole Adekanmi, and I head a seven men tender board in charge of contract awards and payment approvals, I came to know of you in Search of a reliable and reputable person to handle a very confidential business transaction which involves the transfer of a huge sum of money to foreign account requiring maximum confidence. My colleagues and I are top officials of the NIGERIA NATIONAL PETROLEUM CORPORATION (NNPC) OUR DUTIES INCLUDING EVALUATION AND FORESEEING THE MAINTENANCE OF THE REFINERIES IN ALL THE OIL PIPELINES. We are therefore soliciting for your assistance to enable us transfer into your account the said funds. The source of the fund is as follows, during the last Military regime here in Nigeria this committee awarded a contract of US$400 Million to a group of five construction companies on behalf of the NIGERIA NATIONAL PETROLEUM CORPORATION for the construction of the oil pipeline in Kaduna, Port-Harcourt, Warri refineries, during this process my colleagues and I deliberately inflated the total contract sum to the tone of US$443 Million with the intention of sharing the inflated sum of US$43Million. The Government has since approved the sum of US$443Million for us as the contract sum, but since the contract is only worth US$400Million,the remaining US$43Million is what we intend to transfer to reliable and safe offshore account, we are prohibited to operate Foreign account in our names since we are still in Government. This making it impossible for us to acquire the money in our name right now, I have therefore been delegated as a matter of trust by my colleagues to look for an oversea partner into whose account we can transfer the sum of US$43Million. My colleagues and I have decided that if you / your company can be the beneficiary of this funds on our behalf, you or your company will retain 25% of the total sum of US$43Million while 75% will be for us the officials. We have decided that this transaction can only proceed under the following condition: 1. That you treat this transaction with utmost secret and confidentiality and Conviction of your transparent honesty. 2.That upon the receipt of the funds you will release the funds as instructed by us after you have removed your share of 20%. please acknowledge the receipt of this letter using the above email address. I will bring you into the nomenclature of this transaction when I have heard from you, your urgent response through my email, you will be highly appreciated as we are catching on the next payment schedule for the financial quarter. Please be assured that this transaction is 100% legal/risk free, only Trust can make the reality of this transaction. Best regards, ENGR BANKOLE ADEKANMI.

23 years, 1 month

[linux-audio-dev] Paper: sub-msec latency on a shielded CPU on SMP

by Benno Senoner

Interesting article about achieving sub-msec response times by "dedicating" one of the CPUs of a SMP box to high priority tasks using a CPU shielding method. http://www.linuxdevices.com/articles/AT8610061752.html Unfortunately most of us have only single CPU boxes which means that we rely on the performance of the low latency / preemptive patches. According to Jussi L. the 2.4 patches seem currently having problems with ext3 writes (journaling) but ReiserFS seems ok. Jussi told me too that it seems that RedHat 8.0 does something nasty because he got bad latencies on that distro (2.4+his -jl improved lowlat patch). Any news on that front ? What worries me is Red Hat 8.0 since it will become a pretty popular distro soon because it is targeted for the desktop. This means soon we will have user complaining why their systems cannot deliver solid sub-3msec latency. Hopefully ext3 and other issues get fixed soon. cheers, Benno -- http://linuxsampler.sourceforge.net Building a professional grade software sampler for Linux. Please help us designing and developing it.

23 years, 1 month

[linux-audio-dev] Please test my MidiSport firmware loader

by Clemens Ladisch

Hi, I've created a package which extracts the firmware for MidiSport devices from the Windows driver files and installs the hotplug script to download the firmware. You can get it at <http://www.informatik.uni-halle.de/~ladischc/midisport_linux_firmware.html>. There are some differences to Lars Doelle's GPL firmware: - it supports MidiSport 4x4/8x8/Keystation/Oxygen - no configuration file editing, just 'make install' - it requires ALSA because the Midiman firmware doesn't conform to the USB MIDI specification I don't have a MidiSport device, so this is completely untested. Regards, Clemens

23 years, 1 month

Re: [linux-audio-dev] Please test my MidiSport firmware loader

by Pedro Lopez-Cabanillas

Good hack, Clemens! > I've created a package which extracts the firmware for MidiSport devices > from the Windows driver files and installs the hotplug script to download > the firmware. You can get it at > <http://www.informatik.uni-halle.de/~ladischc/midisport_linux_firmware.html >>. > > There are some differences to Lars Doelle's GPL firmware: > - it supports MidiSport 4x4/8x8/Keystation/Oxygen > - no configuration file editing, just 'make install' > - it requires ALSA because the Midiman firmware doesn't conform to the USB > MIDI specification > > I don't have a MidiSport device, so this is completely untested. As Fernando said, it works. I have a Midisport2x2, but I don't need the Midiman's firmware, because my Midisport2x2 works very well with ezusbmidi firmware by Lars Doelle, but this can be useful for 4x4 and 8x8 owners... while there is not a better GPL solution. BTW, the latest midisport GPL firmwares and sources are available at linux-hotplug project CVS repository: http://sourceforge.net/cvs/?group_id=17679 (modulename "firmware") Regards, Pedro -- ALSA Library Bindings for Pascal http://alsapas.alturl.com

23 years, 1 month

[linux-audio-dev] LADSPA output controller?

by Mario Lang

Hi. I've been thinking about what could make LADSPA more fun, and I think its time for a little analog step sequencer. If I make it behave like a real analog step sequencer, Ill need a frequency output and a trigger output. Problem is, vcf303 for instance takes a controller as trigger. So I'd need to connect a audio/controller output to a controller input of another LADSPA plugin. Do ladspa hosts like ecasound support this? Or am I taking a completely wrong route here and it should be done differently? -- CYa, Mario

23 years, 1 month

RE: [linux-audio-dev] image problem

by Andrew W. Schmeder

<quote who="Mark Knecht"> > I do not see how a company could afford to invest in this area, short of > staying closed-source. Very difficult for them, so no wonder there are few companies calling Linux developers. Another difficulty with the GPL its somewhat sketchy legal basis. (OT for LAD... Google if you want to know more). I've noticed that Dual licencing GPL/Commercial seems to fit in with the corporate mindset, however. (e.g. Mysql). Ardour/Libardour could go this route if all the developers desired it. --- Andrew W. Schmeder

23 years, 1 month

[linux-audio-dev] Re: [Jackit-devel] questions about diskthread/process() synchronization

by Kai Vehmanen

On Wed, 13 Nov 2002, Paul Davis wrote: >>my conclusion is that the level of atomicity provided by >>linux asm-arch/atomic.h is not needed to implement >>single-reader-single-writer lock-free buffers. > this is true unless the pointer/index isn't atomic. since on SMP sparc > systems, the arrangement of the cache lines means that you can't > guarantee better than 24 bit atomic values, you do have to be careful > about the potential size and memory position of the pointer/index > variables. I've browsed through the sparc arch manuals and couldn't find anything that would limit atomic access to 24 bits nor any directly related cache line limitations. The Linux asm-sparc/atomic.h provides only 24bits as it uses the lower 8bits to implement a low-overhead spinlock. Spinlock is required to guarantee memory ordering (also with mixed usage of various atomic_* ops). If you just read/write 32bit ints, this is atomic even on SMP-sparcs. >>in handling the l-f buffer indices. In the worst case >>reported write-space is larger, or read-space smaller, >>than the actual situation. > actually, the worst case for both metrics is that they are *smaller* > than they should be. this happens on two occasions: Ugh, true, my mistake. > its not so much "atomicity" as "ordered" that is needed here. because > read/write will only use that part of the buffer indicated as > available by the r/w pointers, all we have to know is that the writes > to the buffer complete before the write pointer is updated. it would > be good to use a so-called "memory barrier" somewhere there to make > sure this is true. Ok, this is a real problem, but I don't think using asm-arch/atomic.h (which can guarantee ordered access to the buffer indices) helps to solve this issue, so you might just as well use regular ints as the atomic indices. And this really is a corner case as the buffer would have to be close to empty (something has already gone wrong!) to read old data from the buffer, even on a SMP sparc or s390. -- http://www.eca.cx Audio software for Linux!

23 years, 1 month

[linux-audio-dev] Who maintains vkeybd?

by Mario Lang

Hi. Yesterday I hacked a bit on vkeybd, and managed to turn the vkb.c into tclkvb.so, such that I now can do $ tcl tcl% load "./tclkvb.so" and use the tcl commands like SetDevice midi set mididev 0 SeqOn ... and so on. This basicly means we could write tcl scripts which use the vkeybd backend, without having to use tk. Or even write different frontends... So I'd like to get this mod out there somehow, but the authors email of vkeybd does no longer work... -- CYa, Mario | Debian Developer <URL:http://debian.org/> | Get my public key via finger mlang(a)db.debian.org | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

23 years, 1 month

Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]

by Patrick Shirkey

Len wrote: >> >If you will be making money from a Linux-based product, then you >> >*should* be investing your own money for promotion. >> >> I am. What's your point? >Other people (people who are not in business) need not and likely won't >invest money to promote Linux Audio. >People here invest their time and effort (but usually not money for >promotion), mostly because they're techies who want to to build >something that they really need/want. Businesses invest money for >another reason, because they want to develop and promote commercial >products. They're mostly two different worlds (though there is >crossover). Would you agree that the commercial side of Linux Audio development is not currently showing much support for the community then? Would you consider it to be partly (if not largely) because there is an image problem. >> I have a small business and there are others out there in similar >> positions. We don't have the financial resources to fund large scale >>ad campaigns on our own. But we do if we work together. >Perhaps there's no need to promote Linux Audio; perhaps instead there >is a need to promote useful products. If those products happen to need >Linux (and ALSA & Jack) as a foundation, then Linux will get promoted >as a side effect of successful products. Much like MacOS. >So if you want Linux Audio to be promoted, either make broadly useful >products or assist the companies that want to turn your work into >broadly useful products. Are you making an offer? ;) While trawling then net today looking at the google search on the word "sound". I saw your site was listed in the first few pages. That's some tough competition there. If we had a community run organisation that lead by example do you think it would make you feel more motivated to promote Linux as a platform to your customers? Esp. If you could show them that your company has an active part in supporting the community? Eg. Official status in the form of certification or advertising space, naming rights, awards in your honour... BTW. Would you like to add your Company to the Tech Support database? http://www.djcj.org -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

23 years, 1 month

[linux-audio-dev] Re: [Jackit-devel] questions about diskthread/process() synchronization

by Kai Vehmanen

Btw; I'll cc'd this to lad, as this is a topic that has been discussed there _many_ times. More specifically the SMP-sparc case has been mentioned quite a few times but without specific details. For lad-only readers, see the jackit-devel archives for the whole thread. On Wed, 13 Nov 2002, Tim Goetze wrote: > it should be noted that this relies on accesses to the > r/w buffer indices to be atomic. that's no problem on > common workstation hardware, though. [...] > /usr/src/linux/include/asm-<target>/atomic.h gives more > info. Actually I've spent some time studying this issue and my conclusion is that the level of atomicity provided by linux asm-arch/atomic.h is not needed to implement single-reader-single-writer lock-free buffers. More specifically, asm/atomic.h provides guaranteed ordering of reads and writes. This is not really needed in handling the l-f buffer indices. In the worst case reported write-space is larger, or read-space smaller, than the actual situation. The only problematic scenarios are that a) read returns an invalid value, and b) write stores an invalid value. These could possibly happen if reads/writes were not atomic. But so far I haven't found any platforms (with publically available specs) which don't guarantee this level of atomicity (even in the case of complex processor cache arrangements). The two architectures for which asm-xxx/atomic.h contains special code even for plain reads and writes are SMP-sparc and s390. I haven't studied s390, but at least in the case of sparcs (ref: sparc v8 arch manual), reads and writes are atomic even in a SMP configuration, although ordering is not guaranteed. More specifically, if TSO (Total Store Ordering) memory mode is selected, loads do not necessarily appear in order. If using PSO (Partial SO), stores as seen by the issuing processor can be executed out-of-order. But these restrictions aren't really a problem for l-f buffers. If I've interpreted the situation incorrectly, or someone has better information, I'd be very interested to know! Even better, example code that demonstrates atomicity problems... I have currenly access to both IA32 and Sparc-v8 multi-processor machines. -- http://www.eca.cx Audio software for Linux!

23 years, 1 month

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev November 2002