Re: [LAD] remember ??
On Tue, Jun 22, 2010 at 04:50:46PM -0400, Gene Heskett wrote: On Tuesday 22 June 2010, f...@kokkinizita.net wrote: Hello all, those of you who attended LAC2009 will recognise the Sala Bianca and lovely metal girl Giorgia: http://www.youtube.com/user/WinterHaze01 Enjoy ! Unforch Fons, while its decent video, the total silence is deafening. Flash 10 doing the playing according to the report from swiftfox, on mdv 2010-x64. I didn't even try watching in firefox. I just stuck the video URL into youtube-dl, then used mplayer to listen. Flash video in firefox general isn't stable for me on any linux machine. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is RME HDSPe AES supported by alsa?
On Thu, May 06, 2010 at 10:46:33AM -0700, Niels Mayer wrote: Certainly the firmware development time is costly, but it's also already been spent and other than ongoing maintenance, a cost that has most likely already been recouped as well. The real question is are they continuing to put FPGA's in their new prosumer oriented products, such as http://www.rme-audio.de/download/sheets/babyface_e.pdf (nb: the term FPGA is used 0 times in this document). If RME is not using a FPGA in the babyface, then they are probably using a 3rd party chipset. http://www.enterpoint.co.uk/moelbryn/raggedstone1.html indicates the starting point for just the spartan 3, and support chips is already above what most prosumer cards cost -- $100.00. Unlike custom VLSI, you can't just plop a FPGA on the pci bus. Note that the Xilinx isn't the only chip on this card: http://www.soundworks.dk/images/rme/hdsp9632_big.jpg -- there's at least 6 other chips in the digital part of the card, some of high-complexity/integration/cost based on their pincount -- in addition to the Xilinx chip. That includes an additional Xilinx chip (flash memory??) that is clearly visible on the above pictured board. I don't know where they establish their prices from. If you look on Digikey, you will see that you can get some quite capable FPGAs for $15-20. FPGAs that can easily handle a 72x72 matrix AND a PCI bus (directly connected to PCI), and some amount of hardware mixing. Spartan3s can use a standard SPI PROM for configuration (a big improvement over the Spartan IIs), which probably costs about $3ish. You also likely need an oscillator, which might be about another $4. And these prices are for single unit quantities. If you order $1000 at once, you will start to see the price be lower still. Keep in mind, what might really drive up the size of the required FPGA would be the 8192 point mixer, which is something that no prosumer card does. A lot of cards with CME and Via VLSI chips also use normal off the shelf ADCs, DACs, and/or digital audio recievers and transmitters, so clearly these aren't the sole determiner of cost. Now, I've never seen the insides of a device with a large number of channels of IO that didn't use an off the shelf FPGA or DSP, so perhaps some higher end products from Apogee or Avid do put everything into one ASIC. Some business people will give a back-of-the-envelope calculation that a $20.00 increase in parts cost translates to a $100.00 increase in consumer cost. And the above estimated $100 parts cost of an RME's fpga and support chips translates to a card that costs $500.00 more e.g. http://www.amazon.com/RME-Hammerfall-9652-Audio-Interface/dp/B0002H030S/ RME can and will continue to do what it does very well -- and priced at you get what you pay for rates. I would venture to say that 5:1 might be a reasonable profit margin for a company RME's size. I know that is what a previous employer who made (among other things) multi-channel digital audio products aimed for. Just seems that since they've got the entire thing already programmed out in an FPGA, they could build a VLSI at little incremental cost. It's not like they're starting from scratch... And given the look of the BabyFace perhaps some of their new products will indicate a shift towards this strategy (?). Sorry, but switching to a VLSI is probably a very large incremental cost. While the company I worked for was too small to make VLSIs, the rule of thumb I heard was a minimum order in the millions of dollars (usualy figure I see in EDN is something like $2 million). Going from HDL to chip masks is apparently not entirely automated, and once the masks are designed, actually making them and setting up a production line is extremely expensive. After that, each chip made is very cheap. Maybe I'm old fashioned, but I've always seen FPGA as something to use for one-off or very low-volume projects. For example http://www.fpgaarcade.com/ :-) But I have no idea of how many cards RME sells a year. Actually, that would be a very interesting number, just to get an idea of the order-of-magnitude size of the pro end of the DAW market.. Sure, but very low volume is probably anything under a quarter of a million units. Just for the heck of it, does anyone have any idea how many Protools Digi units are sold in a year? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] resampling with sp/dif
On Mon, Apr 19, 2010 at 12:38:35PM +0200, Conrad Berh?rster wrote: Hello, i want to grab some external sources (cdplayer) with jack. i run a jack instance with 48000 Hz and it works perfectly with my cd player and ardour. but if i take a cheaper cdplayer, the signal will only be came in with 44100, because there seems no resample and sync between the master (soundcard) and slave (cheapoCD) . so, the signal will always being played to slow. i found a workaround with a small external box, which resamples the incoming signal before it get into the soundcard. Your spdif sound card might have a sample rate converter. If it did, most likely the work flow would be to set jack at 48k and then just play normally and the sound card would convert from the incoming 44.1k to the 48k it is set to. The SRC chip in your sound card (again, presuming it has one, which I think is likely) is probably similar to whatever is in the external box you've tried. Since a while, i think about a software solution, which puzzles me a bit. if i doing the process without the external resampler, what must be done with the signal. If the original source is 44100 Hz, the incoming signal is 48000 (because of jack). if i try to resample it, the current buffer get shorter, because the signal need to be decreased. How can a correct resampling process be done? Unless there is a real need to do this in realtime, say for a live performance, I would suggest just ripping the CD and using a software sample rate converter on the resulting files. I'd be surprised if this couldn't be done in better than realtime on todays systems, meaning you might be able to rip and convert a 60 minute CD in under 30 minutes. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Has anyone ever played a plugin in realtime ... [related to:] hard realtime performance synth
On Sun, Feb 07, 2010 at 12:18:51AM +0100, Jens M Andreasen wrote: snip example of sse assembly versus Cuda In which one of those two codepaths would you like to spend your spare time? Which one looks the most civilized? Just wondering ... snip a bit more [OK... That might be enough CUDA advocacy for tonight? :-D] The cuda stuff is impressive, and may well be the way of the future. However, I don't think it is generally right for linux audio until I can write cuda code (or a similar language) and have it run on Nvidia cards, ATI cards, at least one card using open source drivers, and plain CPUs using SSE (and/or threading). It seems that any quarter now, OpenCL may be close to meeting the qualifications I set (use with Nvidia, ATI, free drivers, and CPU only), however, I don't believe that the OpenCL language is as nice or easy to use as Cuda. Is there any work on an open source clone of Cuda? Obviously any individual programmer can do what they want, but I believe that as a community, GPUs are not yet ready for us to be using them, not strictly for technical reasons, but primarily for freedom and interoperability reasons. I am really eager to see this change though. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Has anyone ever played a plugin in realtime ... [related to:] hard realtime performance synth
On Mon, Feb 08, 2010 at 10:01:03PM +0100, Emanuel Rumpf wrote:
Actually OpenCL seems to already be supported, (in new hardware only ?),
by the large graphic players:
http://www.nvidia.com/object/cuda_opencl.html (there's a lot of docu
here too !)
http://developer.amd.com/gpu/atistreamsdk/pages/default.aspx
http://www.khronos.org/opencl/
I am aware of Nvidia and ATI binary drivers supporting OpenCL. What I
do not see is an ability to run this using the Nouvou, the RadeonHD xorg
driver, the intel xorg driver, or as SSE optimized software only.
If OpenCL DSP code would run on my desktop using CPUs only, faster than
a reasonable C implementation using primitives would run, then I'd
suggest it is ready for people to start using without holding out for
open source driver support. I don't think that we are close enough to
say that we will be there in 6-12 months yet though. If I am mistaken
about the state of the Khronos reference implementation or the clang
implementation, I'd love to see a demo prove me wrong.
There's also the CT Technology from Intel (aquired from RapidMind),
which is claimed to be easier to code and less hardware-dependant than OpenCL.
http://software.intel.com/en-us/data-parallel/
http://software.intel.com/sites/products/collateral/hpc/ct/ct_newsletter1109.html
I am passingly aware of them, but as long as there is not an open
language specification, and an open implementation, I don't think they
are a real answer either.
however, I don't believe that the OpenCL language is as nice or easy to
use as Cuda. ?Is there any work on an open source clone of Cuda?
A link to a short Intro. The code looks acceptable at a first glance:
http://ati.amd.com/technology/streamcomputing/intro_opencl.html
Just because I don't like it as well does not mean I won't accept it as
a valid choice.
However, the examples there still look a lot more complicated that the
cuda examples. The page you posts included a fairly minimal OpenCL
example that is close to 40 lines long without showing the actual source
code for the actual OpenCL function to execute on the card.
_global__ void inc_gpu(int *a, int N)
{
int idx = blockIdx.x * blockDim.x + threadIdx.x;
if (idx N)
a[idx] = a[idx] + 1;
} }
int main()
{
float *a;
dim3 dimBlock (blocksize);
dim3 dimGrid( ceil( N / (float)blocksize) );
cudaMalloc((void **) a, N);
cudaMemcpy(a, someLocalSource, N*sizeof(float), cudaMemcpyHostToDevice);
inc_gpudimGrid, dimBlock(a, N);
cudaFree(a);
}
The __global__ says that it will be called from the host but run on the
device. Calling the function uses a modified call syntax to setup the
arrangement of hardware resources that will be used by the call, but the
number of units to use, and the block size to carve the data by. dim3 is
a cuda defined datatype.
Still, if OpenCL shows up in Mesa, and can at a minimum run on the CPU
faster than a basic C implementation, then I would certainly choose it
over Cuda for open-ness.
I still somehow wonder, how cheap low MHz Chips can outperform my
GHz PC system. The answer seems to be parallelism of computations,
which the GPUs (or DSPs) support better than CPUs.
This also means, that faster CPUs won't necessarily bring
the effect we are waiting for.
(To play many software effects/instruments in an acceptable time.)
Well, I bet a lot of software isn't wringing as much performance for
your PC as it could. When it comes to music though, exactly what low
mhz chips are beating a 2ghz Core 2 Duo or equivelent AMD? Also, how
does the cost of said low mhz device compare to the Core 2 Duo?
However, even in PCs, the trend is more cores, and either programmers
need to get better, or else we need better tools. Now, I certainly plan
to become a better programmer, but I still want better tools, and I
think it is unfair to expect everyone to get better.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [OT] vector drawing software
On Wed, Jul 30, 2008 at 10:00:28PM +1000, Erik de Castro Lopo wrote: Fons Adriaensen wrote: * Inkscape. After two hours of trying I still can't draw a simple rectangle. It gets filled (in blue) and all attempts to change that have failed. Draw the rectangle (it will be blue), then go to the Object menu and choose Fill and Stroke. In the Fill pane, wind the Alpha down to zero. In the Stroke Paint pane chose the second box Flat Color. You should now have a black rectangle, without any fill colour on a white background. It would be better to choose no fill (the X on the fill tab) rather than just making it 0 alpha. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Writing a library?
On Jul 22, 2008, at 10:26 PM, Darren Landrum wrote: I've been looking around for a library to read and write SFZ files, which is an open sampler format released by Cakewalk: http://www.cakewalk.com/DevXchange/sfz.asp Finding none, I thought I might try my hand at writing a library for this myself, as there is no embedded wave information like with Gig files. SFZ is simply a text file to be parsed. Now, I know about writing a good header file, and its associated class, and all that, but I have no knowledge of how to write it as a dynamic library. Google searches on every possible permutation have been worthless to me as well. I would prefer to write it in C++, as that's what I know, and even then, not too well, hence why I thought I'd start with something simple like parsing a text file. If anyone has any advice, recommendations, or ideas, I'll happily listen and learn. I have yet to think too much about how the data will be stored in the class, and what methods to make available to access it, so if anyone knows any best practices there, I'd really like to know. Consider this a feeler post. I'd strongly suggest you consider learning C if you want to maximize other people using your library. If you write the library in C++ it will be hard for anyone but C++ users to use it. If you write it in straight C, or at least expose a plain C interface, it will be trivial to use for C users, C++ users, Objective C users, Python users, Smalltalk users and some scheme and lisp users, and I'm sure I'm missing other languages that can interface with C easily. Also, I suggest that you learn how to use a lex program like Flex. You could also possibly use a parser generator, something like yacc/ bison on top of that. The time spent learning flex will be time very well spent and the time spent learning it will probably pay itself back immediately as your write your tokenizer. There are quite a few good free lex and/or yacc guides available, often on university web sites. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Writing a library?
On Wed, Jul 23, 2008 at 03:25:47PM +0200, Julien Claassen wrote: Hi! Paul: As I understood the sfz format is text-based. I didn't take a look. But depending on what it looks like, a parser generator might be good advice. If the SFZ is an xml variant libxml might be better suited. I looked at the page and it is not XML. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
