Re: [linux-audio-dev] request to use latencytest (OSDL)
Roger Larsson wrote:
>
> ...
> An alternative would be Andrew Mortons amlat - it is simpler, possibly better
> in an automated environment.
That would require a kernel patch.
I always use a mucked-with version of Mark Hahn's `realfeel'
application. Simple, accurate.
Attached here.
/*
* This was originally written by Mark Hahn. Obtained from
* http://brain.mcmaster.ca/~hahn/realfeel.c
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define _GNU_SOURCE
#include
/* global vars */
int stopit; /* set to stop measuring */
#define SAMPLES 1
int histogram[SAMPLES]; /* Milliseconds */
#define PAGE_SIZE 4096UL /* virtual memory page size */
#define OSCR_HZ 3686400 /* frequency of clock ticks */
#define OSCR0x9010 /* physical address of OSCR register */
unsigned long *oscr;/* ptr to OSCR */
void setup_clock (void)
{
int fd;
void *map_base;
off_t target;
off_t page;
#ifndef ARCHARM
return;
#endif
fd = open ("/dev/mem", O_RDWR | O_SYNC);
if (-1 == fd) {
perror ("open of /dev/mem failed\n");
exit (1);
}
/* Map one page */
target = OSCR;
page = target & ~(PAGE_SIZE - 1);
map_base = mmap (0, PAGE_SIZE, PROT_READ, MAP_SHARED, fd, page);
if (MAP_FAILED == map_base) {
perror ("mmap failed");
(void) close (fd);
exit (2);
}
oscr = map_base + (target - page);
/* This does not end the mmap,
* the mmap will go away when the process dies
*/
close (fd);
}
double second() {
struct timeval tv;
gettimeofday(&tv,0);
return tv.tv_sec + 1e-6 * tv.tv_usec;
}
typedef unsigned long long u64;
u64 rdtsc() {
u64 tsc;
#ifdef ARCHARM
tsc = *oscr;
#else
__asm__ __volatile__("rdtsc" : "=A" (tsc));
#endif
return tsc;
}
void selectsleep(unsigned us) {
struct timeval tv;
tv.tv_sec = 0;
tv.tv_usec = us;
select(0,0,0,0,&tv);
}
double secondsPerTick, ticksPerSecond;
void calibrate()
{
double sumx = 0;
double sumy = 0;
double sumxx = 0;
double sumxy = 0;
double slope;
// least squares linear regression of ticks onto real time
// as returned by gettimeofday.
const unsigned n = 30;
unsigned i;
for (i=0; i 2048) {
fprintf(stderr, "max allowable interrupt frequency is 2048 Hz\n");
hz = 2048;
}
else if (hz <= 0) {
fprintf(stderr, "zero or negative frequency doesn't make sense!\n");
hz = 1;
}
}
}
if (argv[optind] == NULL) {
fprintf(stderr, "histogram file name required\n");
usage();
exit (2);
}
return argv[optind];
}
#define msec(f) (1e3 * (f))
int main(int argc, char *argv[])
{
int fd;
double ideal;
u64 last;
double max_delay = 0;
char *histfile = parse_options(argc, argv);
if (mlockall(MCL_CURRENT|MCL_FUTURE) != 0) {
perror("mlockall");
exit(1);
}
setup_clock ();
set_realtime_priority();
calibrate();
printf("secondsPerTick=%f\n", secondsPerTick);
printf("ticksPerSecond=%f\n", ticksPerSecond);
fd = open("/dev/rtc",O_RDONLY);
if (fd == -1)
fatal("failed to open /dev/rtc");
ideal = 1.0 / hz;
if (ioctl(fd, RTC_IRQP_SET, hz) == -1)
fatal("ioctl(RTC_IRQP_SET) failed");
printf("Interrupt frequency: %d Hz\n",hz);
if (bounded) {
printf("running for %d samples\n", ncycles);
}
/* Enable periodic interrupts */
if (ioctl(fd, RTC_PIE_ON, 0) == -1)
fatal("ioctl(RTC_PIE_ON) failed");
signal(SIGINT, signalled);
last = rdtsc();
while (!stopit) {
u64 now;
double delay;
int data;
int ms;
if (read(fd, &data, sizeof(data)) == -1)
fatal("blocking read failed");
now = rdtsc();
delay = secondsPerTick * (now - last);
if (delay > max_delay) {
max_delay = delay;
// printf("%.3f msec\n", -(1e3 * (ideal - delay)));
}
ms = (-(ideal - delay) + 1.0/2.0) * 1;
if (ms < 0)
ms = 0; /* hmmm */
if (ms >= SAMPLES)
ms = SAMPLES;
histogram[ms]++;
if (bounded) {
if (++current >= ncycles) {
printf ("finished collecting %d samples\n", ncy
Re: [linux-audio-dev] priority inversion & inheritance
>From: [EMAIL PROTECTED] > >Soft real-time: average case is X, standard deviation is Y >Hard real-time: worst case is X. Thanks for the defs. What is the practical worst case in standard Linux in terms of audio latency (say)? Last I checked the worst case was good enough for disk recorder/player. It sounded like you rejected standard Linux as a choise for low-latency audio. It is like you're giving up the low-latency development for standard Linux for that reason. Juhana
Re: [linux-audio-dev] LADPSA v1.1 SDK Provisional Release
On Fri, Jul 12, 2002 at 03:28:29 +0200, Martijn Sipkema wrote: > > So, one vote for adding the version > > to the API ? > > I would like to add that old LADSPA plugins can be easily identified > because they lack the \'version\' symbol, so there really is not segfault > problem as far as I can see. Except in old hosts trying to load v2.0 plugins. - Steve
Re: [linux-audio-dev] Re: Exact desicption of PCM system for ALSA
>> encoding, the value (generally) varies between -(2^N) and (2^N)-1, >> where N is the number of bits used to store the value. So a 16 bit >> value will vary between -65536 and 65535. there are other ways of > >Errr, I think you meant "... between -(2^(N-1)) and 2^(N-1)-1 ... " >So you get a range between -32768 and 32767 for 16 bit signed >or between 0 and 65536 for unsigned 16bit. yes, indeed i did. sorry for the error. this reply is just to confirm that alex is right, and i am wrong :)
Re: [linux-audio-dev] Re: Exact desicption of PCM system for ALSA
Hi Paul, > encoding, the value (generally) varies between -(2^N) and (2^N)-1, > where N is the number of bits used to store the value. So a 16 bit > value will vary between -65536 and 65535. there are other ways of Errr, I think you meant "... between -(2^(N-1)) and 2^(N-1)-1 ... " So you get a range between -32768 and 32767 for 16 bit signed or between 0 and 65536 for unsigned 16bit. Cheers, Alex
Re: [linux-audio-dev] priority inversion & inheritance
On Fri, Jul 12, 2002 at 04:01:29PM +0300, Juhana Sadeharju wrote: > >From: [EMAIL PROTECTED] > >> > >> I agree. That's why it is needed. And for realtime threads SCHED_FIFO/RR > > > >You lost me there. A RT scheduler is needed for RT tasks. > > You're selling RT Linux, right? Of course. But RTLinux is a result of my technical bias, not a well considered commercial plan. > The standard Linux in our application can be considered as > a real-time system because audio cards etc. are RT systems. > Even in a true RT system our software applications may fail > to execute. The difference is in where we are tuning the system. Soft real-time: average case is X, standard deviation is Y Hard real-time: worst case is X. -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com
Re: [linux-audio-dev] Re: Exact desicption of PCM system for ALSA
>Yes I did have a look at this tutorial and it has been quite good,
>but I don't understand the signal which is produced there.
>I guess this seems to be a digital 101010... signal.
>But it sounds like an disordered signal and I don't
>understand how to unfluence the volume or the of frequency this signal.
>I actually have an algorythm for sine signals but it's too complex
>for undestanding.
>The problem isn't the interfacing via snd_pcm_open or snd_pcm_writei
>but I don't understand the data which is sent.
>I think the best for me would be an exact description of the PCM
>Signal description system which is also used in Windows Soundcard
>interface libraries ( or not? ). Perhaps someone knows good (E)books
>or tutorials about that.
its sound to me as though you need to a basic text on digital audio.
sound is a pressure wave. microphones convert the pressure wave into
continously varying voltages. an analog to digital converter reads the
voltage level many thousands of times per second, and converts the
voltage reading to a single digital value. with so-called "PCM"
encoding, the value (generally) varies between -(2^N) and (2^N)-1,
where N is the number of bits used to store the value. So a 16 bit
value will vary between -65536 and 65535. there are other ways of
encoding the value of the voltage, but the "PCM" method is by far the
most common.
all of the above happens on your audio interface. all ALSA does is to
allow you to read and write the values generated/used by the audio
interface. if you configured the audio interface for 16 bit samples,
then the data ALSA provides/collects from you is an array of 16 bit
entities ("short" in C terminology). if you configured it for 32 bit
samples, you have an array of 32 bit values. etc.
if the interface has more than one channel (as just about every one of
them does), then you also have to deal with the way that the data from
each channel is arranged. ALSA allows you to ask for interleaved
access, in which the samples from each channel are arranged one after
the other. if the card has two channels, therefore, the array contains
a sample for the left channel, then a sample for the right channel
taken at the same time, then the next sample for the left channel,
followed by the corresponding sample for the right channel etc.
but you can also ask ALSA for non-interleaved access, in which case
the data for each channel exists in completely separate arrays. most
hardware only supports one of these access methods, but ALSA can
"fake" either of them.
--p
Re: [linux-audio-dev] LADPSA v1.1 SDK Provisional Release
> >Well, it\'s not _that_ important, but there are a few good reasons... > > > >1) The LADSPA API was not designed for ABI changes (most notably the > > interface version is not exported by plugins). This means that > > old plugins that you didn\'t remember to delete/recompile can > > cause segfaults in hosts. And unfortunately when you get a seg.fault, > > you probably manage to try at least n+1 other things, send > > bug reports, drive the host developers insane, etc, etc before > > you notice that you had an old pluing lying around. ;) > > So, one vote for adding the version > to the API ? I would like to add that old LADSPA plugins can be easily identified because they lack the \'version\' symbol, so there really is not segfault problem as far as I can see. --martijn Powered by ASHosting
Re: [linux-audio-dev] priority inversion & inheritance
>From: [EMAIL PROTECTED] >> >> I agree. That's why it is needed. And for realtime threads SCHED_FIFO/RR > >You lost me there. A RT scheduler is needed for RT tasks. You're selling RT Linux, right? The standard Linux in our application can be considered as a real-time system because audio cards etc. are RT systems. Even in a true RT system our software applications may fail to execute. The difference is in where we are tuning the system. Anyway, this discussions is very useful. Best regards, Juhana
Re: [linux-audio-dev] Re: Exact desicption of PCM system for ALSA
Hi Philipp, > But it sounds like an disordered signal and I don't > understand how to unfluence the volume or the of frequency this signal. > I actually have an algorythm for sine signals but it's too complex > for undestanding. It seems like you're missing the basic understanding how digitial audio works at all. For example take your CD player at home. The music has to be recorded digitally in a studio in the first step. The analog signal of the music is quantized in a certain resolution. That can be an arbitrary number of bits, usually 8, 16, 24 bits. For a CD that's 16bits. Thus the former analog signal is now represented by 2^16 different voltages or given as a signed integer you have a possible range between -32768 and 32767 for your audio signal or in other words, that are the maximum values for the amplitude of your sound signal. Ok, now I could go on about the sampling frequency and other stuff. But I'm too lazy :*) > Signal description system which is also used in Windows Soundcard > interface libraries ( or not? ). Perhaps someone knows good (E)books > or tutorials about that. Have a look into the source of small audio applications. And for basic information search the internet. A good resource for dsp/audio programming is http://www.harmony-central.com Cheers, Alex
[linux-audio-dev] Re: Exact desicption of PCM system for ALSA
Hello dear Dr. Nagorni, Yes I did have a look at this tutorial and it has been quite good, but I don't understand the signal which is produced there. I guess this seems to be a digital 101010... signal. But it sounds like an disordered signal and I don't understand how to unfluence the volume or the of frequency this signal. I actually have an algorythm for sine signals but it's too complex for undestanding. The problem isn't the interfacing via snd_pcm_open or snd_pcm_writei but I don't understand the data which is sent. I think the best for me would be an exact description of the PCM Signal description system which is also used in Windows Soundcard interface libraries ( or not? ). Perhaps someone knows good (E)books or tutorials about that. 73 de DO1YPV ( Philipp Vollmer )
Re: [linux-audio-dev] priority inversion & inheritance
On Fri, Jul 12, 2002 at 10:31:14AM +0200, Peter Hanappe wrote: > [EMAIL PROTECTED] wrote: > > On Fri, Jul 12, 2002 at 01:40:42AM +0200, Peter Hanappe wrote: > > > >>[EMAIL PROTECTED] wrote: > >> > >> > >>>For example, in RTLinux, fifos shared > >>>between Linux (non-rt) processes and RT threads are asymmetric: the > >>>RT thread never blocks, the non-RT thread blocks. In many cases > >>>it is best to optimize the data operations and perform them under > >>>a spin_lock with interrupts disabled. In RTLinux pthread_spin_lock > >>>disables irqs and, in SMP also sets the lock > >>> pthread_spin_lock(&myq.spin); > >>> myq.tail->next = new; > >>> new->next = 0; > >>> myq.tail= next; > >>> if(!myq.head)myq.head = new; > >>> pthread_spin_unlock(&myq.spin); > >>> > >>How do you tell a blocking non-RT thread that new data is available? > >> > > > > It's done automatically by a write: a write does sends a soft interrupt to > > Linux and the interrupt handler does a standard wakeup on flagged fifos. > > This wakeup doesn't involve a call to the scheduler? > It does - but to the Linux scheduler. > > > > -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com
Re: [linux-audio-dev] LADPSA v1.1 SDK Provisional Release
> 2) Marketing. Only way to make developers believe that your >ABI is truly stable and will not change all the time is >to keep it stable. Just saying that "after this change there >won't be any modifications" every six months just doesn't cut it. >Whether this is a problem for LADSPA is another issue. > Well, that's a good point. So I would vote for just adding a xml file to each plugin, containing default values for ports or other stuff. Cheers, Alex
