linuxaudio.org

On Thu, 2010-07-15 at 13:45 +0200, Robin Gareus wrote:

quoted text
> On 07/15/2010 01:07 PM, Ralf Mardorf wrote:

> > On Thu, 2010-07-15 at 12:55 +0200, Clemens Ladisch wrote:

> >> Ralf Mardorf wrote:

> >>> - instead of dev.hpet.max-user-freq=64 I'll try 1024 or 2048 as Robin

> >>> mentioned

> >>

> >> This parameter will not have any effect on anything because there is no

> >> program that uses the HPET timers from userspace.

>

> That'd be correct if Ralf would stick to 'amidiplay' and friends for his

> tests.

While at least one friend throw his Apple MacOs through the window. I'm

not kidding. Modern computers + music + my friends = not good. I've got

two kinds of friends, the once who say I shouldn't use a modern computer

and the others who say, I should buy Nuendo and expensive hardware. And

btw. I don't have got 1000 friends, but just a handful.

If I would ask my neighbours to listen, they would be fine with bad

timing, regarding to their habits, listening to the radio at prime time.
Anyway, I could ask people to listen, but I'm sure this would be

useless.
> There are a couple of audio-tools who can use either RTC or HPET for

quoted text
> timing, although most of them need an option to explicitly enable it.

>

> >> When high-resolution

> >> timers are used by ALSA, this is done inside the kernel where there is

> >> no limit on the maximum frequency.

>

> Thanks for that explanation. It makes perfect sense.

> I take it the same must be true for dev.rtc.max-user-freq as well.

>

> BTW. Do you know the unit of these values?

>   cat /sys/class/rtc/rtc0/max_user_freq

>   cat /proc/sys/dev/hpet/max-user-freq

> are they Hz?

>

> linux-2.6/Documentation/hpet.txt does not mention it at all and

> linux-2.6/Documentation/rtc.txt hints it's Hz but does not explicitly

> say so.

>

> >> Regards,

> >> Clemens

> >

> > IIRC someone on jack-devel mailing list had issues when using mplayer

> > with the value 64 and it was solved when using the value 1024. But as I

> > mentioned before, for my USB MIDI there was a difference between system

> > timer and hr timer, but there was no difference for the value 64 and

> > 1024, when using hr timer.

> >

> > Btw. I don't understand what a maximum frequency in the context does

> > mean. If 64 or 1024 should have impact, what would be the result?

> >

> > System timer for a kernel-rt is set up to 1000Hz and hr timer is at

> > 1000000000Hz.

> >

> > What is 'max-user-freq' for?

>

> It limits the maximum frequency at which user-space applications can

> [request to] receive "wakeup calls" from the hr-timer.

>

> see also the "Timers" thread on LAD last November:

> http://linuxaudio.org/mailarchive/lad/2009/11/7/161647

Okay, what ever user-space might be, I assume regarding to the

explanations it's unimportant for rt. And as mentioned by the text of

the link, I can confirm that at least my USB MIDI is better when using

hr timer.
I'll test amidiplay, but again, playing all MIDI instruments at the same

isn't the major problem, perhaps just for me, resp. for people with

'golden ears'.
The major issue is sync to audio recordings of MIDI instruments, while

doing audio recordings of other, resp. the same instruments again.
I e.g. do only have one DX7 and one Matrix-1000 and my TG33 (with vector

control) is broken, hence I can't use all outputs, but one stereo output

of the TG33.
I wish to be able to record a synth several times. This means that even

inaudible jitter will become audible, for a production.
Of course I won't record one drum after the other from any of my drum

modules, because this just would result in more noise, but recording the

snare or kick separated to other drum samples is needed, when doing the

mastering by Linux and using a compressor like JAMin.
Accumulation of jitter, caused by recording one instrument after the

other is breaking the groove.
>

quoted text
> > Cheers!

> >

> > Ralf

> >

> >

> best,

> robin

:)
Ralf
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev