On Friday 10 October 2003 11:31, hexe_2003(a)directbox.com wrote: In cheesetracker, only one thread writes to the DSP and manages audio .. the main one is for the GUI. Intercomunication between both is done via shared memory, unless on destructive operations, where locking is performed. (lock on the gui, and trylock on the audio thread). This is to ensure that jack will not kill the app :) Juan Linietsky

On Saturday 11 October 2003 13:50, Tim Orford wrote: Hi ! I am not the author of ladcca, Bob Ham is. I personally am happy about it! :) Cheers Juan Linietsky

On Sun, 2003-10-12 at 16:55, Tim Orford wrote: It's not really dead, it's just been a while since the last release. I've been focused (more) on finding a job recently, so lad stuff has taken a bit of a back seat. I am still plugging away at it tho. Well.. at the moment, it's not really usable for production systems, and the last release was in March :) I'm not sure what would be updated. There's a lot of stuff that's changed/changing from the last release; the server interface protocol is more usable and I'm intending to change the project file format to XML and do some other cleaning up. The conditions for the next release are these being finished, and being able to actually use the system to make some music without any problems. I wouldn't want to guess at when that'll be though. I'll put the code in CVS soon and mail the list. Bob -- Bob Ham <rah(a)bash.sh> "At some point, keystroke recorders got installed on several machines at Valve. Our speculation is that these were done via a buffer overflow in Outlook's preview pane." -- Gabe Newell on the Half-Life 2 source leak

Hi all, I' ve done some tests on a bunch of songs in different compressed formats ( samplerate = 44100 ): Mp3 and Ogg. For the Mp3 format I tested various bitrates and I find out that on the playback phase this format has a value of 26.12 milliseconds/frame ( meaning that every frame cover 26.12 ms! ). For the Ogg format I tested only a nominal bitrate of 192 Kb and I find out a value of 23.22 milliseconds/frame. These values are taken with an error of about 10^(-6) seconds. My ask: is there a general algorythm to calculate the ms/frame value for all conpressed formats? Could someone confirm my values? Are this values affected from some parameters ( I think surely samplerate... )? Why different values for Ogg and Mp3? Ogg will be affected by bitrate? Thanks to all people! J_Zar Gianluca Romanin

On Fri, Nov 14, 2003 at 09:20:47AM -0500, Fred Gleason wrote: - snip - FYI, from the vorbis docs: Vorbis provides none of its own framing, synchronization or protection against errors; it is solely a method of accepting input audio, dividing it into individual frames and compressing these frames into raw, unformatted 'packets'. The decoder then accepts these raw packets in sequence, decodes them, synthesizes audio frames from them, and reassembles the frames into a facsimile of the original audio stream. Vorbis is a free-form variable bit rate (VBR) codec and packets have no minimum size, maximum size, or fixed/expected size. Packets are designed that they may be truncated (or padded) and remain decodable; this is not to be considered an error condition and is used extensively in bitrate management in peeling. Both the transport mechanism and decoder must allow that a packet may be any size, or end before or after packet decode expects. Vorbis packets are thus intended to be used with a transport mechanism that provides free-form framing, sync, positioning and error correction in accordance with these design assumptions, such as Ogg (for file transport) or RTP (for network multicast). So, if I'm reading this correctly, the vorbis framesize is not fixed within the general spec, so you'd have to be prepared for all sorts of frame sizes. 784 - Michael C. Piantedosi - drclaw(a)dogsolitude.org