Re: Fwd: [Ardour-Cvs] Ardour source branch meterbridge updated. 3.2-153-gf885622
Jörn Nettingsmeier <[email protected]>
| Newsgroups | gmane.comp.audio.ardour.devel |
|---|---|
| Message-ID | <[email protected]> |
On 07/06/2013 08:34 PM, Robin Gareus wrote: > On 07/06/2013 06:27 PM, Jörn Nettingsmeier wrote: >> hi robin, i'm not currently tracking the meterbridge branch, so i may be >> talking nonsense, but here goes: >> peaking should be defined as a configurable number of samples at full >> scale (or equal to or greater than 1.0f, in the case of floats) , not >> some arbitary level. > > > Hi Jörn, > > Do you have a reference for this *should be* defined as? I don't think > that makes much sense. > > Actually it's rather the other way 'round. Since the digital signal is > band-limited there can be peaks in the audio even if the digital samples > are not exceeding 0dbFS [1]. maybe i misunderstood the purpose of this code snippet (like i said, i don't know the context). if this is about a peak hold feature, ignore me. if it's about peaking in the sense of "clipping", bear with me. within a digital audio system based on floats, i don't have to care about peaks at all. only at the last step before going back to fixed-point or analog do i have to adjust. so all i want to see from a peak indicator is "has my data been clipped at some earlier point in the chain?". i don't really care about inter-sample peaks at this stage. fwiw, the current implementation in ardour is not foolproof either: when i overload my micstasies, the peak indicator will show 0.0dB but not turn red, so i've learned to look for the numbers rather than the color. of course, it could also be that the preamp does not ever deliver fullscale for some reason... > Either way this is not relevant yet. The meterbridge branch (which will > be merged back to master soonish) is currently mostly concerned with GUI > - not the actual calculations. i see. > NTL, the level-metering in ardour will see a major rework in the not to > distant future - and doing that needs a rethink. > > Your suggested approach has one major downside though: it cannot be > efficiently accelerated with SSE2 (thanks to Sampo, the current > max-peak-hold is accelerated). > > Other level-meters standards/algorithms will have the same issue and > because every port in ardour has a peak-meter and you can have thousands > of ports this can become a major DSP-load bottleneck. thousands of ports? never :-D > Anyway - this needs careful planning. > > Thanks for kicking off this discussion.. looking forward to this new code! btw, i should have written to you about it, but i've been using the video timeline for a little project last week (usual workflow: video guy decides edits and delivers the final video with rudimentary guide track from built-in mics). worked like a charm, thanks a lot! best, jörn -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net