16
Audio / Re: Continuous Audio for Synthersys
« on: June 14, 2016, 10:10:15 pm »
Hi Laurent,
What sort of size should I be using?
What sort of size should I be using?
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: 1 [2]
17
Audio / Re: Continuous Audio for Synthersys
« on: June 14, 2016, 09:54:14 pm »
Fair point Mario.
I am generating samples in batches of 2 * 441. (2 channels, 44100 sample rate, therefore a "key-pressing resolution" of 1/100th of a second.)
I'm getting a small amount of delay when requesting a new batch of samples which is causing the audio playing to "stutter" and introduce that horrible noise I described earlier.
I have compiled in release mode with O3 optimization level.
What can I do about this?
I am generating samples in batches of 2 * 441. (2 channels, 44100 sample rate, therefore a "key-pressing resolution" of 1/100th of a second.)
I'm getting a small amount of delay when requesting a new batch of samples which is causing the audio playing to "stutter" and introduce that horrible noise I described earlier.
I have compiled in release mode with O3 optimization level.
What can I do about this?
18
Audio / Re: Continuous Audio for Synthersys
« on: June 13, 2016, 04:01:51 pm »
Hi there, Yes I was not aware of this tutorial. Thanks.
First question I have is in regards to mutexes and getting data about what keys are pressed inside the onGetData function, which is where I believe I should generate my next batch of samples. (Say I generate 4410 at a time or something...?)
What's the best way to approach this?
I have a possible idea which is to have a globally accessible bool variable, which tells me whether the Z key is pressed or not. Then if I do something like...
Then in my onGetData function, do the same thing, with a sf::Lock to lock the mutex before checking if Z is pressed?
Am I thinking about this in the correct manner? Perhaps I shouldn't be using global variables?
First question I have is in regards to mutexes and getting data about what keys are pressed inside the onGetData function, which is where I believe I should generate my next batch of samples. (Say I generate 4410 at a time or something...?)
What's the best way to approach this?
I have a possible idea which is to have a globally accessible bool variable, which tells me whether the Z key is pressed or not. Then if I do something like...
// global
bool is_Z_pressed = false;
sf::Mutex mutex; // protect global variables?
int main()...
{
// main loop sets the bool is_Z_pressed to true/false
// wrap accessing the bool using sf::Lock(mutex)
// access to this variable in a local scope so that the mutex is unlocked when sf::Lock falls out of scope?
{
// local scope
sf::Lock(mutex);
if(event.key.code == Key::Z)
is_Z_pressed = true;
... etc
}
}
bool is_Z_pressed = false;
sf::Mutex mutex; // protect global variables?
int main()...
{
// main loop sets the bool is_Z_pressed to true/false
// wrap accessing the bool using sf::Lock(mutex)
// access to this variable in a local scope so that the mutex is unlocked when sf::Lock falls out of scope?
{
// local scope
sf::Lock(mutex);
if(event.key.code == Key::Z)
is_Z_pressed = true;
... etc
}
}
Then in my onGetData function, do the same thing, with a sf::Lock to lock the mutex before checking if Z is pressed?
Am I thinking about this in the correct manner? Perhaps I shouldn't be using global variables?
19
Audio / Continuous Audio for Synthersys
« on: June 13, 2016, 02:02:13 pm »
Hi all,
I am trying to figure out a way to use the SFML toolkit in a real-time audio synthesis project. (As a kind of experiment, just for fun.)
SFML would be handy since I can use the RenderWindow etc to create a basic UI.
It appears to me that there are 2 methods I could use.
The first is with sf::Sound and sf::SoundBuffer.
The second is with sf::SoundStream.
Let us consider a program which plays a 440 Hz sin wave when I press a key, such as the Z key on my keyboard, otherwise silence is played.
Let us discuss the first, first.
***Soundbuffer***
I have two possible ideas here, although I don't think either will work particularly well. The first idea is to generate a buffer, say for 0.1 s of sound, fill it as the event loop is processed by checking the elapsed time and filling in that duration of sin wave or silence depending on whether the Z key is pressed. Then every time the event loop "goes over" a 0.1 s interval, play the new buffer contents and start generating a new buffer to play.
This method has a problem. Typically, there will be a delay between the thread which is playing the audio finishing playing samples, and a new call to sf::Sound.Play() to play the new buffer. In addition, the sound playing will always be delayed by 0.1 s. (Which is quite large, and results in a horrendous 0.1 s low frequency noise being added to the signal by the continual stop/starting.)
To reduce this problem, one could allocate enough memory for 30 s of audio, press the keys, and then hear the output 30 s later. Obviously the problem here is you are limited to 30 s of audio, and you can't hear what you're playing until afterwards.
The only resolution would be to detect when the playing thread has finished, and then immediately play some new buffer. This will reduce delays, but there will still be some, and I am unsure if this can be done... I think there may be a better way.
***SoundStream***
After attempting to implement the first method, and finding essentially that "it doesn't work very well", as you probably suspected, I did some more researching and found the sf::SoundStream object.
Is this the correct object to use for this task?
I have had a look at the VOIP example, but found this didn't really help much as there is a load of network stuff there which makes it difficult to decipher what is happening if one is not familiar with network programming.
After studying this example, I found a further problem which is that this example appears to work by recording sound samples on one PC and sending them to another. Hence it doesn't really matter too much if there is an associated delay. (I am not sure what this delay might be. I assume less than ~ 0.2 s, but it won't really matter for a phone conversation so long as it's not "too" large.)
Going back to sf::Soundstream, it is my understanding that I must overload the "onGetData" and "onSeek" functions in my own derived class.
What are these functions supposed to do, and how should I overload them? I assume the onGetData() function should "generate new samples", but how many? Where should I store these samples? How can I discard old samples which are no longer required? What if I want to simultaneously record a .wav file to media?
Finally, what does the "onSeek" function do? Why would I need to "seek" in an audio bitstream if I am writing something like a synthesizer?
Apologies for the long question, I tried to make it clear what I am asking.
By the way, I haven't actually asked the main question yet, which is; "is soundstream" the best method of implementing this? Is there another, better method? Perhaps I should be using another external library which is not SFML based at all?
I am trying to figure out a way to use the SFML toolkit in a real-time audio synthesis project. (As a kind of experiment, just for fun.)
SFML would be handy since I can use the RenderWindow etc to create a basic UI.
It appears to me that there are 2 methods I could use.
The first is with sf::Sound and sf::SoundBuffer.
The second is with sf::SoundStream.
Let us consider a program which plays a 440 Hz sin wave when I press a key, such as the Z key on my keyboard, otherwise silence is played.
Let us discuss the first, first.
***Soundbuffer***
I have two possible ideas here, although I don't think either will work particularly well. The first idea is to generate a buffer, say for 0.1 s of sound, fill it as the event loop is processed by checking the elapsed time and filling in that duration of sin wave or silence depending on whether the Z key is pressed. Then every time the event loop "goes over" a 0.1 s interval, play the new buffer contents and start generating a new buffer to play.
This method has a problem. Typically, there will be a delay between the thread which is playing the audio finishing playing samples, and a new call to sf::Sound.Play() to play the new buffer. In addition, the sound playing will always be delayed by 0.1 s. (Which is quite large, and results in a horrendous 0.1 s low frequency noise being added to the signal by the continual stop/starting.)
To reduce this problem, one could allocate enough memory for 30 s of audio, press the keys, and then hear the output 30 s later. Obviously the problem here is you are limited to 30 s of audio, and you can't hear what you're playing until afterwards.
The only resolution would be to detect when the playing thread has finished, and then immediately play some new buffer. This will reduce delays, but there will still be some, and I am unsure if this can be done... I think there may be a better way.
***SoundStream***
After attempting to implement the first method, and finding essentially that "it doesn't work very well", as you probably suspected, I did some more researching and found the sf::SoundStream object.
Is this the correct object to use for this task?
I have had a look at the VOIP example, but found this didn't really help much as there is a load of network stuff there which makes it difficult to decipher what is happening if one is not familiar with network programming.
After studying this example, I found a further problem which is that this example appears to work by recording sound samples on one PC and sending them to another. Hence it doesn't really matter too much if there is an associated delay. (I am not sure what this delay might be. I assume less than ~ 0.2 s, but it won't really matter for a phone conversation so long as it's not "too" large.)
Going back to sf::Soundstream, it is my understanding that I must overload the "onGetData" and "onSeek" functions in my own derived class.
What are these functions supposed to do, and how should I overload them? I assume the onGetData() function should "generate new samples", but how many? Where should I store these samples? How can I discard old samples which are no longer required? What if I want to simultaneously record a .wav file to media?
Finally, what does the "onSeek" function do? Why would I need to "seek" in an audio bitstream if I am writing something like a synthesizer?
Apologies for the long question, I tried to make it clear what I am asking.
By the way, I haven't actually asked the main question yet, which is; "is soundstream" the best method of implementing this? Is there another, better method? Perhaps I should be using another external library which is not SFML based at all?
20
Window / Re: How thread safe is a sfml window?
« on: July 24, 2013, 04:13:58 am »
Okay thanks once again Laurent for your speedy replies!
21
Window / How thread safe is a sfml window?
« on: July 22, 2013, 06:21:14 pm »
I notice there is a section in the tutorials about threads and sfml.
The example is how to use a thread to render on a sfml window.
I presume that this is thread safe?
How safe would be event handling in the same loop? I assume this must be safe, because events must be handled somewhere, whether this be in the main loop or the rendering loop.
This is a question about sfml generally, although I am mostly interested in OpenGL rendering and event processing. How thread safe are these things?
What sort of things are and are not thread safe. If something isn't thread safe, what is likely to be the best way of making it so? (Mutex, atomic operations, etc)
The example is how to use a thread to render on a sfml window.
I presume that this is thread safe?
How safe would be event handling in the same loop? I assume this must be safe, because events must be handled somewhere, whether this be in the main loop or the rendering loop.
This is a question about sfml generally, although I am mostly interested in OpenGL rendering and event processing. How thread safe are these things?
What sort of things are and are not thread safe. If something isn't thread safe, what is likely to be the best way of making it so? (Mutex, atomic operations, etc)
22
System / Re: Why is there no thread.join() with SFML threads library?
« on: July 04, 2013, 02:39:24 pm »
Okay that's great thanks very much.
Seems a shame not to use sf::thread, because then everything would be "sf" - nice and uniform. But without .join() I would be a bit stuck, and since there isn't an advantage to use sf::thread, I won't bother with the hassle of learning the subtle differenced between then.
Cheers for the quick answer(s).
Seems a shame not to use sf::thread, because then everything would be "sf" - nice and uniform. But without .join() I would be a bit stuck, and since there isn't an advantage to use sf::thread, I won't bother with the hassle of learning the subtle differenced between then.
Cheers for the quick answer(s).
23
System / Why is there no thread.join() with SFML threads library?
« on: July 04, 2013, 02:06:45 pm »
I am working on a project with SFML, version 2, and I had been using std::thread for running some threads.
I am wondering why sf::thread does not require a join() function? And why is has a launch function whereas the standard library does not.
Also, since sfml is cross platform, what are the advantages and disadvantages between sf::thread and std::thread?
Apologies if this question has been answered before, the search isn't working at the moment. It displays an error message asking me to report the problem to an administrator. Hopefully and admin will see this, and then I will have done what the message told me to!
I am wondering why sf::thread does not require a join() function? And why is has a launch function whereas the standard library does not.
Also, since sfml is cross platform, what are the advantages and disadvantages between sf::thread and std::thread?
Apologies if this question has been answered before, the search isn't working at the moment. It displays an error message asking me to report the problem to an administrator. Hopefully and admin will see this, and then I will have done what the message told me to!
Pages: 1 [2]