In DirectSound, there was a very distinct concept of circular buffers
In particular there was a current read position, a current write position, and clear methods to GetPosition and lock the buffer and start writing.
I'm looking for a similar concept in OpenAL, but all I can find is looping an AL_STREAMING buffer, and using AL_SAMPLE_OFFSET to determine the current read position (and write say, 15 samples after that?)
OpenAL docs are down right now, but accessible here.
What is a safe way to declare a sound buffer that gets written to by the application as it is playing? Am I right about using a looping streaming buffer?
Actually circular buffers in OpenAL are much different than for DirectSound.
In OpenAL, you must queue sound buffers, one after the other. You really only need 2 sound buffers then, and you just continuously call alSourceQueueBuffers and alSourceUnqueueBuffers.
Queuing Buffers on a Source
To continuously stream audio from a source without interruption, buffer queuing is required. To
use buffer queuing, the buffers and sources are generated in the normal way, but alSourcei is not
used to attach the buffers to the source. Instead, the functions alSourceQueueBuffers and
alSourceUnqueueBuffers are used. The program can attach a buffer or a set of buffers to a
source using alSourceQueueBuffers, and then call alSourcePlay on that source. While the
source is playing, alSourceUnqueueBuffers can be called to remove buffers which have already
played. Those buffers can then be filled with new data or discarded. New or refilled buffers can
then be attached to the playing source using alSourceQueueBuffers. As long as there is always
a new buffer to play in the queue, the source will continue to play.
Related
I am trying to execute when the active buffer has changed by either
Changing the buffer in the current window (e.g. C-x <left>).
Switching to another window (C-x o).
Switching to another frame.
Are their hooks suitable for detecting this?
What I figured out so far
Looking through the Standard Hooks I found the following options, none of which quite do what I want:
buffer-list-update-hook is called for both (1) and (2). It is however unsuitable, because it is run before the buffer is changed, while I want to know what the current-buffer after the change is.
window-configuration-change-hook can be used to detect a change of the buffer displayed in the current window, and it is run after the change, as needed. It is however not run for M-x other-window.
mouse-leave-buffer-hook seems viable for detecting mouse-based window switching, but it gets called a bit often (for me four times upon switching windows with the mouse, three times before and once after switching), which requires additional logical to prevent multiple execution.
post-command-hook would be viable but a bit heavy handed, risking significant slow-down of the editor by even minor bugs.
Since my action would need to use with-selected-window, which triggers these hooks, care has to be taken to avoid endless loops where the hook triggers itself.
Judging from the comments, the answer to this question is “No, there is no such hook.”
Additionally, some of the hooks mentioned in my question, are also triggered by changes, which are not user-visible, such as temporary changes due to with-current-buffer and with-selected-window.
However, using post-command-hook has proven to be a non-issue for performance, since the required state-check is cheap.
Alternative
Probably obvious, but stated for completeness.
Store state information in a global variable, in a frame-parameter, in a window-parameter or in a buffer-local variable, whichever is most applicable to the use-case. In my use-case, this necessary unique state is was defined by current-buffer, current-window, and in one case line-beginning-position.*
In post-command-hook, check if the state has changed, possibly skipping
even that, if this-command is self-insert-command.
If it has, perform the intended action and update the stored state.
* line-number-at-pos is unsuitable, because it counts lines by iterating over the buffer from point-min to point, making it generally cheap, but not cheap enough to be executed after every typed character.
Emacs27.1 introduce a new variable called `window-buffer-change-functions'
I'm not sure what the normal behaviour is here, but I would like to have multiple workgroups, each with its associated buffers. So, for example, I could have my-python-workgroup which has a bunch of python files open in the buffer, and a my-ssh-workgroup which has buffers associated with a server connection.
Right now it seems like once I launch emacs and switch between workgroups, my buffers end up accumulating. Is there any way to keep buffers separate?
Spacemacs has this capability through what it calls 'Layouts'. Layouts gives you buffer isolation, so that you can keep your python and ssh buffers in separate groups, for instance. You can also save and load layouts. See here:
https://github.com/syl20bnr/spacemacs/tree/master/layers/%2Bspacemacs/spacemacs-layouts
The disadvantage is that it does not save shells (ehsell, ansi-term, inferior python, etc.), so you can't load up a combination of python files and an inferior python buffer on restart. Workgroups2 has this capability, but it does not allow buffer isolation. It would be great if these two concepts could be combined!
How would you automatically "record" a slime repl session? By "record" I probably mean to auto-save what the repl buffer has, similar to any code buffer's auto-save. I'm sure "state" would be a much tougher issue, but at least to save the buffer contents would be a start. Of course I could just do a save C-x-s and name it something like repl20131115-111034.srepl, but to have a behind-the-scenes auto-save capability (including timestamp in the file name) would be nice.
Psychotherapy
I asked this question about Lisp 20 years ago, about R a year ago and I am not asking it about python now. So, let me try to answer it.
What you asked for
Timed Logs
You certainly do not want the automatic repl-timestamp.log files - they will fill up your disk and you will never actually look at them.
Auto Save
Yeah, you can save the lisp interaction buffer into a file (and then the buffer will be auto-saved periodically), but you do not want that either.
You are much better off typing your code in a buffer associated with a lisp file and sending it to the lisp interaction buffer, and only copying the "interesting" lisp output back to your file buffer. E.g., you do not want to save all 42 bad versions of a function, just the working one (and maybe a few intermediate ones - but you have git and hg for that).
What you really need
What you really want it two things:
Remember what you did
Restore the state where you left off
Here is how to do that:
Remember what you did
You can use dribble to save into a file both what you type and what Lisp replies.
This is useful, however, I think I examined only very few of the zillions of dribble files I created in my newbie days.
They are there mostly for your peace of mind.
Restore the state
This is what lisp images are for: they write to disk the "state of the lisp universe" so that you can start from where you left off.
I have two buffers open side by side in Emacs. As I delete (or modify) lines in the first file, I would like the second file to receive the same commands / cursor position. Is this possible?
The closest thing I know of to what you've described is the multiple-cursors package, which is pretty cool, but it only implements multiple cursors within a single buffer. So I suppose that you could:
Append one of the buffer contents to the other;
Spawn multiple cursors using the package I mentioned;
Split the windows;
Edit away;
Move the appended buffer contents back to its original location.
With what I suspect would be a considerable amount of hacking, one might be able to extend multiple-cursors to handle multiple buffers, but I think this would be opening up a huge can of worms. What if the two buffers are in different modes, and you enter a key sequence that's bound to different commands that do vastly different things?
I recently had the privilege of setting $| = 1; inside my Perl script to help it talk faster with another application across a pipe.
I'm curious as to why this is not the default setting. In other words, what do I lose out on if my buffer gets flushed straightaway?
Writing to a file descriptor is done via system calls, and system calls are slow.
Buffering a stream and flushing it only once some amount of data has been written is a way to save some system calls.
Benchmark it and you will understand.
Buffered depends on the device type of the output handle: ttys are line-buffered; pipes and sockets are pipe-buffered; disks are block-buffered.
This is just basic programming. It’s not a Perl thing.
The fewer times the I/O buffer is flushed, the faster your code is in general (since it doesn't have to make a system call as often). So your code spends more time waiting for I/O by enabling auto-flush.
In a purely network I/O-driven application, that obviously makes more sense. However, in the most common use cases, line-buffered I/O (Perl's default for TTYs) allows the program to flush the buffer less often and spend more time doing CPU work. The average user wouldn't notice the difference on a terminal or in a file.