sh0dan - Very good. :) I strongly support having lots of AC3 channels (or ANY AC3). It probably isn't important but I think VS6 does most __int64 math via subroutine call. I don't know have any idea how many samples you would have. Is it close to overflowing in any reasonable circumstance? - Tom
----------------------------------------- ,,,2011 black M3 sedan comp. pk vf 620 sc kit aka "KMPRSSR",,, 2013 x6 5.0 m sport pk "WIFE's",,2007 X5 4.8,,,2013 "BLACK OPPS"
It currently overflows at 12 hours at 48000 smps/sec - so there is still headroom for most people, but I've seen one person reaching this limit, and that's enough for me to consider changing it. Yes - int64 is probably slower than int32, but if we keep "count" as an int32 (which is reasonable), there will not be much code involving the int64's (all loops would be 32 bits). Good point!
----------------------------------------- Techo Violet 96 M3 Coupe Titanium silver 07 328iT Autumn Gold 06 Lotus Elise "The existence of the flamethrower is evidence that someone, somewhere once said 'I want to set those people over there on fire, but I don't want to have to walk over there
Oh - I forgot another important question: Compatebility Is it ok to break compatebility for external audio plugins? This will break compatebility with external plugins using audio. I didn't think there were any, but now I think of, we'll most probably break Edwins compressed audio support plugin, and maybe even his Link2 (I have no use for it, so I wont pay to have it). I would convert it myself, if the code was free. Does anyone know if changing the videoinfo struct will break anything in video plugins, or will they adapt?
Dg, thanks for your input - appreciated! Great to hear that my ramblings completely off. What are the disadvantages of using __int64 - it just seems so much easier? For example: Code:
Completely agree - internal datastructures should be completely hidden from filters. I'll take that into consideration, and make all variables private. Hopefully I'll get some time to try to do a complete conversion in the coming weekend, but I think a 2.0.x stable release should be done before implementing any radical changes, as this is.
forget it :) i guess my suggestion is only relevant for DSP machines, when the machine's accumlator has an extension of an overflow registers, and has built-in scaling mode with flags like sticky & carry that updats automaticly without the need to execute extra code to know if you're in a 'floating-point' mode or in a 'fixed-point' mode. anyway, i'm not sure about execution speed, but working with __int64 could take longer than working with two seperate ints. on the other hand, my knowledge of pentium's architecture is limited to one 4-days course i've taken 3 years ago. so i could be talking BS.. about a BeSynth plugin, what would you need from that ? currently, BeSweet.dll has a input function for mpa & ac3 inputs, i can add an interface for pcm inputs, and i can replace my fwrite() function with AviSynth's callback function. would that suffice.. ?
@DSPguru, BeSynth plugin: would that what you outlined make AviSynth capable of directly inputting e.g. a mp2-Audiostream (e.g. demuxed from a SVCD)? This would be really great, together with Nic's new mpegsource we could import mpeg2 without any external programms.
----------------------------------------- Sean Cain "Filter Out the Competition"