Re: [Traverso-devel] How's it going?

[Jonatan Liljedahl]

(re-sending to the list, i mistakenly sent it to Remon privately..)

Remon Sijrier wrote:
> Hi,
> 
>> Tell me about and I can take a look.
> 
> The whole idea about AudioWave drawing is detecting the highest/smallest 
> value 
> within a certain range.
> By making the range powers of 2, it's easy to calculate level 2^n by the 
> highest values of the 2 values of 2^(n-1)
> 
> From 1:64 and above, we store all values to hard disk, this takes ~ 1.5 % of 
> the real audio size.
> So if we want to display a certain waveform at level 1:1024, we seek to the 
> correct position, and read in n pixels of information.
> 
> But for all other zoomlevels, there needs to be another way of calculating 
> the 
> levels.
> For all levels smaller then 1:64, we read directly all the samples in from 
> hard disk, and calculate the the peaks.
> 
> My idea for say all zoom levels > 1:200 we can use a sufficiently low 
> _cached_ 
> zoomlevel, and interpolate the peaks from there, by for example only 
> interpolate from at max 5 other peak values for each new one.
> 
> So, in case of level 1:325, we calculate the highest level from 5 peak values 
> from the cached peaks 1:64
> For level 1:320, there will be a little offset which should be accounted for 
> in a sensible way.
> 
> Peak::calculate_peaks() has both the < 1:64 (MicroView) and > 1:64 with 
> powers 
> of 2 (MacroView), so the third option as explained above is what needs to be 
> added.
> I hope I made my idea clear.

This stuff needs some thinking. =) I'm currently involved quite deeply
in my own project (a programming environment for algorithmic
composition) which takes most of my brain % so I'm not sure if/when I
will have time to look at this.

>> I've tried to compile the CVS version but didn't succeed, I think it was
>> the missing lv2. But lv2 isn't released yet, and I can't find the source
>> to download. Why not include it in traverso?
> 
> slv2 is needed, it's easier to compile it yourself then that I include it in 
> Traverso at this time.
> Use svn to checkout from:
> http://codeson.net/svn/libslv2/
> 
>> Another thing that is very important for me is to have it work with
>> 44.1KHz mode on 48KHz fixed cards, letting ALSA do the samplerate
>> conversion. Since aplay (alsa player) can do it, so should traverso.
>> It's all about setting the right parameters in the right way, I believe...
> 
> The only thing to get this working would be using plughw, and nothing else.

Yes, there should be menu's for choosing in/out devices. I guess plughw
is not the best choice for someone who has a nice soundcard and wants
low latency. But personally I'm mostly going to use traverso for
playback so additional latency is not much of a problem for me.

> But I remember something about the buffer size too.
> Can you detect somehow what your audiocards prefered buffers size is ?
> I'll reread your mails about this, and see what I can do.

aplay sets
    rate         : 44100
    exact rate   : 44100 (44100/1)
    msbits       : 16
    buffer_size  : 15052
    period_size  : 940
    period_time  : 21333
    tick_time    : 0
    tstamp_mode  : NONE
    period_step  : 1
    sleep_min    : 0
    avail_min    : 940
    xfer_align   : 940

First of all, we should use the *_near variants of the functions for
setting parameters. But there's also some problem with the buffersize,
something about how traverso decides on a buffersize according to the
period_size...?

> If plughw didn't work for you, then there is more then just samplerate 
> conversion.

plughw works fine with aplay on 44.1 files, so it should work with
traverso too!

> If you compile traverso with debug on (look for this setting in src/base.pri) 
> and run with --d2 , does it say something about the reason it fails to create 
> the alsa driver ?

setup() bails out with:

  Cannot configure capture channel: cannot set buffer length to 3072
  for capture.

-- 
/Jonatan    -=( http://kymatica.com )=-