I'm working on a personal command-line driven sound application https://github.com/aparks5/synthcastle and I've run into some trouble.
Question: How can I have a control thread communicate to an audio thread without interruption of the audio?
I want to be able to pass commands from the command line to the audio thread and return back to the command line for further sound manipulation.
The problem is, without multithreading, that if I invoke a command such as "loop 4" (to repeat a pattern 4 times), my "loop" command just waits until the loop finishes before returning execution to the user.
I tried another paradigm by creating a control thread and audio thread, where invoking "loop" immediately returns, caching the passed data along with enqueuing a command to lock-free queue.
In main.cxx:
userData.server = server;
std::shared_ptr<MixerStream> stream = std::make_shared<MixerStream>(SAMPLE_RATE, &userData);
std::thread control(controlThread, stream);
// todo: move graphics thread out of audio thread
std::thread audio(audioThread, stream);
audio.detach();
control.join();
However, when I poll the queue from the audio thread, the data is corrupted and doesn't play in its entirety, only the last bit is played.
int MixerStream::paCallbackMethod(const void* inputBuffer, void* outputBuffer,
...
for (size_t sampIdx = 0; sampIdx < framesPerBuffer; sampIdx++)
{
...
output = m_mixer();
output = clip(output);
*out++ = output;
*out++ = output;
writeBuff[sampIdx] = output;
g_buffer[sampIdx] = static_cast<float>(output*1.0);
}
g_ready = true;
while (m_callbackData->commandsToAudioCallback->size_approx()) {
Commands cmd = *(m_callbackData->commandsToAudioCallback->peek());
m_callbackData->commandsToAudioCallback->pop();
switch (cmd) {
case Commands::START_LOOP:
m_bLoop = true;
while (m_loopTimes > 0) {
playPattern(m_pattern, m_bpm);
m_loopTimes--;
}
break;
case Commands::START_RECORDING:
m_callbackData->server->openWrite();
break;
case Commands::STOP_RECORDING:
m_callbackData->server->closeWrite();
break;
}
m_callbackData->commandsFromAudioCallback->enqueue(cmd); // return command to main thread for deletion
}
...
}
It's clear that nothing should be invoked in paCallbackMethod except for the generation of audio.
It's almost as if I need a third thread in between the UI and the audio, but this doesn't make sense to me.
I'm totally new to multithreading so any pointers as to how I can make control appear seamless would be greatly appreciated.
Update: It's not going to be a perfect solution but my conclusion at the end of my question, creating a third thread so UI -> Control -> Audio actually produced the desired result. I can make loops in the UI, the control thread will poll the stream continuously if it's ready to play, and will issue the commands while the UI is ready to accept new commands. I'm just waiting for it to produce glitches when I try continuous control.
Related
I want to implement a GUI that receives messages from an external device. The "advancedReceiveExample" is waiting for messages. Once it has received one, it does stuff with it, saves it and terminates.
I want to make my function wait for new messages after receiving one as long as the button is toggled.
I have tried this so far:
void MainWindow::on_pushButton_clicked()
{
if (ui.pushButton->isChecked()) {
ui.pushButton->setText("Stop Receiving");
ui.label_3->setText("Receiving...");
advancedReceiveExample(ui.comboBox->currentIndex() + 1);
}
else
{
ui.pushButton->setText("Start Receiving");
ui.label_3->setText("Not Receiving");
}
}
This works perfectly fine but as mentioned above it only receives one message. If I do that:
void MainWindow::on_pushButton_clicked()
{
if (ui.pushButton->isChecked()) {
ui.pushButton->setText("Stop Receiving");
ui.label_3->setText("Receiving...");
while (1)
{
advancedReceiveExample(ui.comboBox->currentIndex() + 1);
}
}
else
{
ui.pushButton->setText("Start Receiving");
ui.label_3->setText("Not Receiving");
}
}
it blocks the function because the state of the button can only be change after the function "on_pushButton_clicked()" has terminated.
Visual Studio 2019
C/C++
EDIT: Okay, I have understood the problem of blocking the thread. Multithreading might be the right option but I am very unexperienced regarding this topic. The <QThread> could be possible. How would you use it?
Do you have suggestions which other library could be used?
Note QT is event-based. If you keep your computer busy inside some function without returning to the main loop frequently, your GUI will freeze.
What you need to do is slice your action that you want to do into small bits that can repeatedly return to the main loop in order to keep the GUI responsive. (Another method yould be to swap out your action into a separate thread and handle it in parallel, killing the thread when the button is released)
Probably the simplest method to do what you want is with timers that you arm in the PushButton::clicked slot, and then check in the timer event whether the button is still pressed, and, if yes, do a bit of your action, save state and re-arm the timer to have you return.
Something along the lines of the following pseudo code should work and execute what you want to do in slices every 10ms:
MainWindow::onPushButtonClicked () {
// do the action, or, alternatively, start a
// parallel thread that does it
do_a_bit_of_action();
// sets up a timer to call onTimer after 10ms
QTimer::singleShot (10, this, SLOT(onTimer()));
}
MainWindow::onTimer () {
// check if button is still held down
if (pushButton.down) {
// re-arm timer
Timer::singleShot (10, this, SLOT(onTimer()));
// do some more action bits
do_a_bit_of_action();
}
else {
// kill optional background thread here
}
}
You can try it with:
while(ui.pushButton->isChecked()){
*your function*
}
I need listen a lot of (<10) external event send to app and process them. Event can happen every 50ms or can is a hour, can't predetermine time or frequency, depend user. System use pthread on linux 3.6.5, single core cpu, ram 512. Listener must start at begin system and stop at end system, don't delay recive event (in 50ms). Moreover, also have a thread run update UI, 2 thread in threadpool to download.
External event here can is mouse click, keyboard key down/up, on/off LCD, button power, press key ir remote, a file modified, a alarm push by server,..
I consider 2 option, a listener on thread or a timer thread.
can any one please explain efficient of performance with both above away when use on descripted system ? and which one would be a better choise or a new option ?
a listener on a thread
//==================================== option 1: use 1 listener/thread
// i = [0, n]
bool waitForEvent_i(){
// can is poll change on a file description, read on socket
// or pthread_cond_wait a other thread
// ...
}
void thread_i(){
while(waitForEvent_i()){
excute_i();
}
}
void startListener(){
startThread_0();
startThread_1();
....
startThread_n(); // n < 10;
}
a pthread such as timer proactive check all event can
//================================== option2: use timer to interval check
class Task{
public:
void run(){
// check if have change, call excute_i()
}
};
void timer_thread(timeout){
while(1){
while(!queue.empty()}
{
task = queue->getTask();
task->run();
usleep(timeout - task->timeExcuted()); // suppose, timeExcuted < timeout
}
usleep(timeout);
}
}
void startTimer(){
start_Timer_thread();
}
I need a code construction for my project which waits for some time, but when there is an interrupt (e.g. incoming udp packets) it leaves this loop, does something, and after this restart the waiting.
How can I implement this? My first idea is using while(wait(2000)), but wait is a void construct...
Thank you!
I would put the loop inside a function
void awesomeFunction() {
bool loop = true;
while (loop) {
wait(2000);
...
...
if (conditionMet)
loop = false;
}
}
Then i would put this function inside another loop
while (programRunning) {
awesomeFunction();
/* Loop ended, do stuff... */
}
There are a few things I am not clear about from the question. Is this a multi-threaded application, where one thread handles (say) the UDP packets, and the other waits for the event, or is this single-threaded? You also didn't mention what operating system this is, which is relevant. So I am going to assume Linux, or something that supports the poll API, or something similar (like select).
Let's assume a single threaded application that waits for UDP packets. The main idea is that once you have the socket's file descriptor, you have an infinite loop on a call to poll. For instance:
#include <poll.h>
// ...
void handle_packets() {
// m_fd was created with `socket` and `bind` or `connect`.
struct pollfd pfd = {.fd = m_fd, .events = POLLIN};
int timeout;
timeout = -1; // Wait indefinitely
// timeout = 2000; // Wait for 2 seconds
while (true) {
pfd.revents = 0;
poll(&pfd, 1, timeout);
if ((pfd.revents & POLLIN) != 0) {
handle_single_packet(); // Method to actually read and handle the packet
}
if ((pfd.revents & (POLLERR | POLLHUP)) != 0) {
break; // return on error or hangup
}
}
}
A simple example of select can be found here.
If you are looking at a multi-threaded application, trying to communicate between the two threads, then there are several options. Two of which are:
Use the same mechanism above. The file descriptor is the result of a call to pipe. The thread sleeping gets the read end of the pipe. The thread waking get the write end, and writes a character when it's time to wake up.
Use C++'s std::condition_variable. It is documented here, with a complete example. This solution depends on your context, e.g., whether you have a variable that you can wait on, or what has to be done.
Other interrupts can also be caught in this way. Signals, for instance, have a signalfd. Timer events have timerfd. This depends a lot on what you need, and in what environment you are running. For instance, timerfd is Linux-specific.
I keep running into this problem of trying to run a thread with the following properties:
runs in an infinite loop, checking some external resource, e.g. data from the network or a device,
gets updates from its resource promptly,
exits promptly when asked to,
uses the CPU efficiently.
First approach
One solution I have seen for this is something like the following:
void class::run()
{
while(!exit_flag)
{
if (resource_ready)
use_resource();
}
}
This satisfies points 1, 2 and 3, but being a busy waiting loop, uses 100% CPU.
Second approach
A potential fix for this is to put a sleep statement in:
void class::run()
{
while(!exit_flag)
{
if (resource_ready)
use_resource();
else
sleep(a_short_while);
}
}
We now don't hammer the CPU, so we address 1 and 4, but we could wait up to a_short_while unnecessarily when the resource is ready or we are asked to quit.
Third approach
A third option is to do a blocking read on the resource:
void class::run()
{
while(!exit_flag)
{
obtain_resource();
use_resource();
}
}
This will satisfy 1, 2, and 4 elegantly, but now we can't ask the thread to quit if the resource does not become available.
Question
The best approach seems to be the second one, with a short sleep, so long as the tradeoff between CPU usage and responsiveness can be achieved.
However, this still seems suboptimal, and inelegant to me. This seems like it would be a common problem to solve. Is there a more elegant way to solve it? Is there an approach which can address all four of those requirements?
This depends on the specifics of the resources the thread is accessing, but basically to do it efficiently with minimal latency, the resources need to provide an API for either doing an interruptible blocking wait.
On POSIX systems, you can use the select(2) or poll(2) system calls to do that, if the resources you're using are files or file descriptors (including sockets). To allow the wait to be preempted, you also create a dummy pipe which you can write to.
For example, here's how you might wait for a file descriptor or socket to become ready or for the code to be interrupted:
// Dummy pipe used for sending interrupt message
int interrupt_pipe[2];
int should_exit = 0;
void class::run()
{
// Set up the interrupt pipe
if (pipe(interrupt_pipe) != 0)
; // Handle error
int fd = ...; // File descriptor or socket etc.
while (!should_exit)
{
// Set up a file descriptor set with fd and the read end of the dummy
// pipe in it
fd_set fds;
FD_CLR(&fds);
FD_SET(fd, &fds);
FD_SET(interrupt_pipe[1], &fds);
int maxfd = max(fd, interrupt_pipe[1]);
// Wait until one of the file descriptors is ready to be read
int num_ready = select(maxfd + 1, &fds, NULL, NULL, NULL);
if (num_ready == -1)
; // Handle error
if (FD_ISSET(fd, &fds))
{
// fd can now be read/recv'ed from without blocking
read(fd, ...);
}
}
}
void class::interrupt()
{
should_exit = 1;
// Send a dummy message to the pipe to wake up the select() call
char msg = 0;
write(interrupt_pipe[0], &msg, 1);
}
class::~class()
{
// Clean up pipe etc.
close(interrupt_pipe[0]);
close(interrupt_pipe[1]);
}
If you're on Windows, the select() function still works for sockets, but only for sockets, so you should install use WaitForMultipleObjects to wait on a resource handle and an event handle. For example:
// Event used for sending interrupt message
HANDLE interrupt_event;
int should_exit = 0;
void class::run()
{
// Set up the interrupt event as an auto-reset event
interrupt_event = CreateEvent(NULL, FALSE, FALSE, NULL);
if (interrupt_event == NULL)
; // Handle error
HANDLE resource = ...; // File or resource handle etc.
while (!should_exit)
{
// Wait until one of the handles becomes signaled
HANDLE handles[2] = {resource, interrupt_event};
int which_ready = WaitForMultipleObjects(2, handles, FALSE, INFINITE);
if (which_ready == WAIT_FAILED)
; // Handle error
else if (which_ready == WAIT_OBJECT_0))
{
// resource can now be read from without blocking
ReadFile(resource, ...);
}
}
}
void class::interrupt()
{
// Signal the event to wake up the waiting thread
should_exit = 1;
SetEvent(interrupt_event);
}
class::~class()
{
// Clean up event etc.
CloseHandle(interrupt_event);
}
You get a efficient solution if your obtain_ressource() function supports a timeout value:
while(!exit_flag)
{
obtain_resource_with_timeout(a_short_while);
if (resource_ready)
use_resource();
}
This effectively combines the sleep() with the obtain_ressurce() call.
Check out the manpage for nanosleep:
If the nanosleep() function returns because it has been interrupted by a signal, the function returns a value of -1 and sets errno to indicate the interruption.
In other words, you can interrupt sleeping threads by sending a signal (the sleep manpage says something similar). This means you can use your 2nd approach, and use an interrupt to immediately wake the thread if it's sleeping.
Use the Gang of Four Observer Pattern:
http://home.comcast.net/~codewrangler/tech_info/patterns_code.html#Observer
Callback, don't block.
Self-Pipe trick can be used here.
http://cr.yp.to/docs/selfpipe.html
Assuming that you are reading the data from file descriptor.
Create a pipe and select() for readability on the pipe input as well as on the resource you are interested.
Then when data comes on resource, the thread wakes up and does the processing. Else it sleeps.
To terminate the thread send it a signal and in signal handler, write something on the pipe (I would say something which will never come from the resource you are interested in, something like NULL for illustrating the point). The select call returns and thread on reading the input knows that it got the poison pill and it is time to exit and calls pthread_exit().
EDIT: Better way will be just to see that the data came on the pipe and hence just exit rather than checking the value which came on that pipe.
The Win32 API uses more or less this approach:
someThreadLoop( ... )
{
MSG msg;
int retVal;
while( (retVal = ::GetMessage( &msg, TaskContext::winHandle_, 0, 0 )) > 0 )
{
::TranslateMessage( &msg );
::DispatchMessage( &msg );
}
}
GetMessage itself blocks until any type of message is received therefore not using any processing (refer). If a WM_QUIT is received, it returns false, exiting the thread function gracefully. This is a variant of the producer/consumer mentioned elsewhere.
You can use any variant of a producer/consumer, and the pattern is often similar. One could argue that one would want to split the responsibility concerning quitting and obtaining of a resource, but OTOH quitting could depend on obtaining a resource too (or could be regarded as one of the resources - but a special one). I would at least abstract the producer consumer pattern and have various implementations thereof.
Therefore:
AbstractConsumer:
void AbstractConsumer::threadHandler()
{
do
{
try
{
process( dequeNextCommand() );
}
catch( const base_except& ex )
{
log( ex );
if( ex.isCritical() ){ throw; }
//else we don't want loop to exit...
}
catch( const std::exception& ex )
{
log( ex );
throw;
}
}
while( !terminated() );
}
virtual void /*AbstractConsumer::*/process( std::unique_ptr<Command>&& command ) = 0;
//Note:
// Either may or may not block until resource arrives, but typically blocks on
// a queue that is signalled as soon as a resource is available.
virtual std::unique_ptr<Command> /*AbstractConsumer::*/dequeNextCommand() = 0;
virtual bool /*AbstractConsumer::*/terminated() const = 0;
I usually encapsulate command to execute a function in the context of the consumer, but the pattern in the consumer is always the same.
Any (welln at least, most) approaches mentioned above will do the following: thread is created, then it's blocked wwiting for resource, then it's deleted.
If you're worried about efficiency, this is not a best approach when waiting for IO. On Windows at least, you'll allocate around 1mb of memory in user mode, some in kernel for just one additional thread. What if you have many such resources? Having many waiting threads will also increase context switches and slow down your program. What if resource takes longer to be available and many requests are made? You may end up with tons of waiting threads.
Now, the solution to it (again, on Windows, but I'm sure there should be something similar on other OSes) is using threadpool (the one provided by Windows). On Windows this will not only create limited amount of threads, it'll be able to detect when thread is waiting for IO and will stwal thread from there and reuse it for other operations while waitting.
See http://msdn.microsoft.com/en-us/library/windows/desktop/ms686766(v=vs.85).aspx
Also, for more fine-grained control bit still having ability give up thread when waiting for IO, see IO completion ports (I think they'll anyway use threadpool inside): http://msdn.microsoft.com/en-us/library/windows/desktop/aa365198(v=vs.85).aspx
I was wondering if C++ had any way of doing interrupts. I want one program to store information in a text file, while the other one prints a statement depending on what is in the text file. Since I want it to be as accurate as possible, I need the print program to be interrupted when the update program updates the file.
C++ itself doesn't give this capability, it knows nothing of other programs that may or may not be running.
What you need to look into is IPC (inter-process communications), something your operating system will probably provide.
Things like signals, shared memory, semaphores, message queues and so on.
Since you seem to be using the file itself as the method of delivering content to the other process, signals are probably the way to go. You would simply raise a signal from process A to process B and a signal handler would run in the latter.
Of course this all depends on which operating system you're targeting.
If you are using Windows you can use FindFirstChangeNotification.
Here's some old code I have. This is run in it's own thread:
DWORD CDiskWatcher::Run(void *vpParameter)
{
CFileNotifyInterface *pIface = (CFileNotifyInterface *)vpParameter;
HANDLE handles[2];
handles[0] = m_hQuitEvent;
handles[1] = ::FindFirstChangeNotification(m_szPath, FALSE, FILE_NOTIFY_CHANGE_LAST_WRITE|FILE_NOTIFY_CHANGE_FILE_NAME);
DWORD dwObject;
if (INVALID_HANDLE_VALUE != handles[1]) {
do {
// Wait for the notification
dwObject = ::WaitForMultipleObjects(2, handles, FALSE, INFINITE);
if (WAIT_OBJECT_0 + 1 == dwObject) {
// Continue waiting...
::FindNextChangeNotification(handles[1]);
pIface->FireFileSystemChange(m_szPath);
}
} while (WAIT_OBJECT_0 != dwObject);
// Close handle
::FindCloseChangeNotification(handles[1]);
}
return 0;
}
Note m_hQuitEvent is created with CreateEvent() and CFileNotifyInterface is for callbacks:
class CFileNotifyInterface
{
public:
virtual void FireFileSystemChange(const char *szPath) = 0;
};