Hi,
I have been lurking on the list so now I want to say
hi.I am part of the ubuntu users group in Brazil.
Can anyone tell me *very briefly* what is the current
state of play regarding realtime-lsm in the 2.6.*
kernels and whether this feature (or something like it
) is likely to be introduced into the kernel anytime
soon.
I cannot find anything on the net apart from some
discussions between the kernel devs and
linux-audio-dev guys which did not really clear
anything up for me.
I am not asking in order to cause a big debate about
the values or otherwise of realtime-lsm but I want to
make sure I am clear about the current situation.
We have made some metapackages based on DeMuDi for the
Ubuntu-BR Multimedia-audio distro and doing something
like this ->
# apt-get install build-essential fakeroot
linux-headers-$(uname -r)
is the only way I can think of to enable realtime-lsm
in the kernel without asking the user to use
module-assistant to enable it after install which is
something we don want to do
Regards
Ian
Linux is more than a business. Linux is a community. Linux is more than an operating system. Linux
is a dream. We know that as computer users, we represent a small percentage of the computer
industry as a whole. The important thing is that we know we're right, and we're going to change
the future of the software industry one long night at a time.
Hi,
I'm working on the Rockbox - http://www.rockbox.org - project, which is
a project to develop an open source (GPL'd) replacement firmware for
portable digital audio p[ayers.
Rockbox has been running on various Archos MP3 players for about 3
years. The latest hardware that Rockbox is in the process of being
ported to is the iRiver H120/H140 players. These consist of a 120MHz
Coldfire (m68k-based) processor and 32MB of RAM. There is no
floating-point support in the Coldfire.
We currently have real-time playback of MPEG audio (via libmad), Ogg
Vorbis (via libOgg), FLAC (via libFLAC), A52/AC3 (via liba52) and (of
course) WAV files.
Unfortunately, the audio hardware only supports a 44.1KHz samplerate -
meaning that we have to resample other frequencies.
The most common case will be downsampling 48KHz->44.1KHz, but there are
also users who need upsampling from various lower frequencies (e.g. for
use with audio books).
So we're looking for pointers to any high quality (but fast!) resampling
code that could be used.
Thanks in advance,
Dave.
Greetings:
I ran memtest for a day, the RAM's fine, so I brought in another
machine, added my drives, memory, and cards, everything's working all right.
Once again I learned a lot, thanks to everyone who replied. But I
gotta get me some new iron...
Best,
dp
This is, I know, slightly off-topic for this group, as it does not deal
with audio per se. It does, however, deal with the
"real-time"/preemptible Linux kernel, for which I think most of the
expertice is gathered here.
The OS is Linux, the computer an ordinary PC. The task we are faced with
is to run a program, tcpreplay, in such a way that it delivers its
network packets as precisely as possible. I.e. the packets should be
delivered to the network with the smallest possible timing error.
We think that the way to minimize this timing error is to use a kernel
with the real-time patches, as this will improve latency and response
times.
The question is how we can assure that the program really utilizes the
real-time capabilities of the kernel. My understanding is that having a
real-time capable kernel is only the first step, the second necessary
step is to get access to this capabilities? So, how does one accomplish
this, given that the program itself does nothing to achieve this?
* Will an ordinary program, run as root, take advantage of the real time
capabilities of the kernel?
* Will an ordinary program, run as a user that is a member of the
"audio" group on f.i. Agnula, take advantage of the real-time capabilities?
* If given a real-time kernel, what else is necessary to take advantage
of its capabilities?
* How does normal priorities (nice, renice) play together with the
real-time kernel?
With kind regards
Asbjørn Sæbø
After my initial problems with jack I must say I have come to like jack.
Especially together with muse. Now I wonder, is there something like a sample
browser (possibly with jack output) that allows traversing through
directories and click-n-play audio files in them? Something like good old
fastwav on windows... I have searched and searched but everything I could
find needs at least two clicks to play.. also kde/qt drag and drop would be
nice..
thanks,
mm
On Thu, 9 Jun 2005 10:05 , 'Chris Cannam' <chris.cannam(a)ferventsoftware.com> sent:
>N Smethurst:
>> Since a vector is a wrapped C array (i.e. contigous), the [] operator
>> compiles to the C equivalent when optimisation is turned on.
>
>I was thinking of iterator operations, having vaguely recalled that the vector
iterator in the gcc library had at some point changed from an actual pointer to a
wrapper class. Looking at the code, though, the wrapper is so thin that it
probably isn't an issue with optimization on.
>
>
I was under the impression that there was bounds checking going on with
vectors. Is this not the case?
Jan
Frailty, thy name is GCC
A Modern Drama in Three Scenes.
Dramatis Personae: An ardent programmer and a popular C++ compiler
-*-
Prologue:
Appalled by the rat race commonly known as the proprietary software
business, our young and gifted hero joins the light side, deeply
inspired by the manifold yet subtle qualities of free software.
Scene I:
Our hero in day-and-night-long sessions optimizes the hell out of a
SSE2-based n*4-band IIR equalizer. Of course in assembly, and mixed
with C++ templating. The final code is about 10% faster than floats on
AMD, probably a fair bit quicker yet on P4 systems.
Enter gcc version 3, which drops multi-line inline assembly support.
Said assembly code becomes effectively unusable and dies a quick and
unsung death.
Scene II:
Our hero puts years of work into an all-round realtime audio and MIDI
library that expands the Python programming language. While having its
flaws, it's a versatile, surprisingly stable and immensely capable
system, partly thanks to a very clever (according to our hero) design
that subclasses Python's C types in C++.
Enter gcc version 3, moving the vtable member to memory offset 0 of a
derived type even if the base type is in C which doesn't know about
vtables. As a result, the very foundation of said library's type
system is rendered nonfunctional since Python expects its type header
to reside in the very same memory location. With no precautions for
such an abrupt change taken and the implications requiring a manual
review and substantial rewrite of a good 50.000 lines of source code,
said library dies a slow and painful but equally unsung death.
Scene III:
Our hero bundles his DSP efforts into a free plugin library, once
again saving himself much work and improving code readability by using
C++ templates, resulting in quite an elegant object system and source
code, hethinks.
Enter gcc version 4, which requires the templated types' constructor
code be rewritten in the most nonsensical, misleading and ugly fashion
possibly imaginable this side of Hungary and Redmond, WA, according to
our (now not so very young anymore) hero.
Epilogue:
Our hero has completely and permanently lost his faith in the popular
compiler. Disillusioned and indecisive, he resigns himself to
henceforth reluctantly write C++ only to support his miserable life.
His plight is so bad he downright refuses to support the latest
follies of the popular compiler in his free software efforts.
-*-
Will this be the end? To be continued, hopefully.
Cheers, Tim
On Thu, 9 Jun 2005 23:41 , David Cournapeau <cournape(a)gmail.com> sent:
>On 6/9/05, stefan kersten steve(a)k-hornz.de> wrote:
>> On Thu, Jun 09, 2005 at 10:31:35PM +0900, David Cournapeau wrote:
>> > _Z6vectorSt6vectorIiSaIiEE:
>> > .LFB539:
>> > .L2:
>> > .L7:
>> > pushl %ebp
>> > .LCFI0:
>> > movl %esp, %ebp
>> > .LCFI1:
>> > popl %ebp
>> > ret
>>
>
>Well, that's what happens when one post some code after some heavy
>coding all day long, and when one tries to answer two questions at the
>same time....That's why I would have prefered to find the relevant
>part instead in the C++FAQ :)
>
> Anyway, for the question "is there bound checking with operator[]",
>the answer of Bjarne Stroustrup is no :).
> The other problem "is [] as efficient for vector and plain c array
>?", well, people who know better than me asm/gcc can test and answer.
>
Yeah, it really needs to be tested to tell. I remember taking a course in
VAX Macro asm back in the days of dinosaur eggs and phonograph needles. The
book, DEC, and the teacher all said you could turn off the VAX debugging mode
when you compiled. I wrote some self-modifying code for one of the exercises (I
wouldn't do that in real life ;-) The compiler still slapped in some debugging
stuff and it wouldn't work. It was a real simple program though so the
instructor checked it and passed it anyway ;-)
Jan
N Smethurst:
> Since a vector is a wrapped C array (i.e. contigous), the [] operator
> compiles to the C equivalent when optimisation is turned on.
I was thinking of iterator operations, having vaguely recalled that the vector iterator in the gcc library had at some point changed from an actual pointer to a wrapper class. Looking at the code, though, the wrapper is so thin that it probably isn't an issue with optimization on.
Chris