2013-09-30 19:37:13 -07:00
|
|
|
/******************************************************************************
|
|
|
|
Copyright (C) 2013 by Hugh Bailey <obs.jim@gmail.com>
|
|
|
|
|
|
|
|
This program is free software: you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
2013-12-02 21:24:38 -08:00
|
|
|
the Free Software Foundation, either version 2 of the License, or
|
2013-09-30 19:37:13 -07:00
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
#include "../util/threading.h"
|
|
|
|
#include "../util/darray.h"
|
2013-10-24 00:57:55 -07:00
|
|
|
#include "../util/circlebuf.h"
|
2013-09-30 19:37:13 -07:00
|
|
|
#include "../util/platform.h"
|
|
|
|
|
|
|
|
#include "audio-io.h"
|
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
struct audio_input {
|
2014-01-19 02:16:41 -08:00
|
|
|
struct audio_convert_info conversion;
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
void (*callback)(void *param, const struct audio_data *data);
|
|
|
|
void *param;
|
|
|
|
};
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2013-10-24 00:57:55 -07:00
|
|
|
struct audio_line {
|
2014-01-09 18:08:20 -08:00
|
|
|
char *name;
|
|
|
|
|
2013-10-24 00:57:55 -07:00
|
|
|
struct audio_output *audio;
|
|
|
|
struct circlebuf buffer;
|
2014-01-09 18:08:20 -08:00
|
|
|
pthread_mutex_t mutex;
|
2014-01-08 15:41:40 -08:00
|
|
|
DARRAY(uint8_t) volume_buffer;
|
2013-10-24 00:57:55 -07:00
|
|
|
uint64_t base_timestamp;
|
|
|
|
uint64_t last_timestamp;
|
|
|
|
|
|
|
|
/* states whether this line is still being used. if not, then when the
|
|
|
|
* buffer is depleted, it's destroyed */
|
|
|
|
bool alive;
|
2014-01-09 18:08:20 -08:00
|
|
|
|
2014-01-09 21:04:25 -08:00
|
|
|
struct audio_line **prev_next;
|
|
|
|
struct audio_line *next;
|
2013-10-24 00:57:55 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
static inline void audio_line_destroy_data(struct audio_line *line)
|
|
|
|
{
|
|
|
|
circlebuf_free(&line->buffer);
|
2014-01-08 15:41:40 -08:00
|
|
|
da_free(line->volume_buffer);
|
2014-01-09 18:08:20 -08:00
|
|
|
pthread_mutex_destroy(&line->mutex);
|
|
|
|
bfree(line->name);
|
2013-10-24 00:57:55 -07:00
|
|
|
bfree(line);
|
|
|
|
}
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
struct audio_output {
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
struct audio_output_info info;
|
2013-10-24 00:57:55 -07:00
|
|
|
size_t block_size;
|
2014-01-08 15:41:40 -08:00
|
|
|
size_t channels;
|
2013-10-24 00:57:55 -07:00
|
|
|
|
|
|
|
pthread_t thread;
|
|
|
|
event_t stop_event;
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2013-10-24 00:57:55 -07:00
|
|
|
DARRAY(uint8_t) pending_bytes;
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2014-01-09 18:08:20 -08:00
|
|
|
DARRAY(uint8_t) mix_buffer;
|
|
|
|
|
2013-10-24 00:57:55 -07:00
|
|
|
bool initialized;
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2013-10-24 00:57:55 -07:00
|
|
|
pthread_mutex_t line_mutex;
|
2014-01-09 18:08:20 -08:00
|
|
|
struct audio_line *first_line;
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
|
|
|
|
pthread_mutex_t input_mutex;
|
|
|
|
DARRAY(struct audio_input) inputs;
|
2013-09-30 19:37:13 -07:00
|
|
|
};
|
|
|
|
|
2013-10-24 00:57:55 -07:00
|
|
|
static inline void audio_output_removeline(struct audio_output *audio,
|
|
|
|
struct audio_line *line)
|
|
|
|
{
|
|
|
|
pthread_mutex_lock(&audio->line_mutex);
|
2014-01-09 18:08:20 -08:00
|
|
|
*line->prev_next = line->next;
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
if (line->next)
|
|
|
|
line->next->prev_next = line->prev_next;
|
2013-10-24 00:57:55 -07:00
|
|
|
pthread_mutex_unlock(&audio->line_mutex);
|
2014-01-09 18:08:20 -08:00
|
|
|
|
2013-10-24 00:57:55 -07:00
|
|
|
audio_line_destroy_data(line);
|
|
|
|
}
|
|
|
|
|
2014-01-19 02:16:41 -08:00
|
|
|
static inline uint32_t time_to_frames(audio_t audio, uint64_t offset)
|
2014-01-09 18:08:20 -08:00
|
|
|
{
|
|
|
|
double audio_offset_d = (double)offset;
|
|
|
|
audio_offset_d /= 1000000000.0;
|
|
|
|
audio_offset_d *= (double)audio->info.samples_per_sec;
|
|
|
|
|
2014-01-19 02:16:41 -08:00
|
|
|
return (uint32_t)audio_offset_d;
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline size_t time_to_bytes(audio_t audio, uint64_t offset)
|
|
|
|
{
|
|
|
|
return time_to_frames(audio, offset) * audio->block_size;
|
2014-01-09 18:08:20 -08:00
|
|
|
}
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
|
2014-01-09 18:08:20 -08:00
|
|
|
static inline void clear_excess_audio_data(struct audio_line *line,
|
|
|
|
uint64_t size)
|
|
|
|
{
|
|
|
|
if (size > line->buffer.size)
|
|
|
|
size = line->buffer.size;
|
|
|
|
|
|
|
|
blog(LOG_WARNING, "Excess audio data for audio line '%s', somehow "
|
|
|
|
"audio data went back in time by %llu bytes",
|
|
|
|
line->name, size);
|
|
|
|
|
|
|
|
circlebuf_pop_front(&line->buffer, NULL, (size_t)size);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t min_uint64(uint64_t a, uint64_t b)
|
|
|
|
{
|
|
|
|
return a < b ? a : b;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void mix_audio_line(struct audio_output *audio,
|
2014-01-10 10:55:54 -08:00
|
|
|
struct audio_line *line, size_t size, uint64_t timestamp)
|
2014-01-09 18:08:20 -08:00
|
|
|
{
|
|
|
|
/* TODO: this just overwrites, handle actual mixing */
|
2014-01-10 10:55:54 -08:00
|
|
|
if (!line->buffer.size) {
|
|
|
|
if (!line->alive)
|
|
|
|
audio_output_removeline(audio, line);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
size_t time_offset = time_to_bytes(audio,
|
2014-01-10 10:55:54 -08:00
|
|
|
line->base_timestamp - timestamp);
|
|
|
|
if (time_offset > size)
|
|
|
|
return;
|
|
|
|
|
|
|
|
size -= time_offset;
|
|
|
|
|
2014-01-12 01:40:51 -08:00
|
|
|
size_t pop_size = (size_t)min_uint64(size, line->buffer.size);
|
2014-01-10 10:55:54 -08:00
|
|
|
circlebuf_pop_front(&line->buffer,
|
|
|
|
audio->mix_buffer.array + time_offset,
|
|
|
|
pop_size);
|
2014-01-09 18:08:20 -08:00
|
|
|
}
|
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
static inline void do_audio_output(struct audio_output *audio,
|
2014-01-19 02:16:41 -08:00
|
|
|
uint64_t timestamp, uint32_t frames)
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
{
|
|
|
|
struct audio_data data;
|
|
|
|
data.data = audio->mix_buffer.array;
|
|
|
|
data.frames = frames;
|
|
|
|
data.timestamp = timestamp;
|
|
|
|
data.volume = 1.0f;
|
|
|
|
|
|
|
|
/* TODO: conversion */
|
|
|
|
pthread_mutex_lock(&audio->input_mutex);
|
|
|
|
for (size_t i = 0; i < audio->inputs.num; i++) {
|
|
|
|
struct audio_input *input = audio->inputs.array+i;
|
|
|
|
input->callback(input->param, &data);
|
|
|
|
}
|
|
|
|
pthread_mutex_unlock(&audio->input_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mix_and_output(struct audio_output *audio, uint64_t audio_time,
|
2014-01-09 18:08:20 -08:00
|
|
|
uint64_t prev_time)
|
|
|
|
{
|
|
|
|
struct audio_line *line = audio->first_line;
|
|
|
|
uint64_t time_offset = audio_time - prev_time;
|
2014-01-19 02:16:41 -08:00
|
|
|
uint32_t frames = time_to_frames(audio, time_offset);
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
size_t bytes = frames * audio->block_size;
|
2014-01-09 18:08:20 -08:00
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
da_resize(audio->mix_buffer, bytes);
|
|
|
|
memset(audio->mix_buffer.array, 0, bytes);
|
2014-01-09 18:08:20 -08:00
|
|
|
|
|
|
|
while (line) {
|
|
|
|
struct audio_line *next = line->next;
|
|
|
|
|
2014-01-09 21:04:25 -08:00
|
|
|
if (line->buffer.size && line->base_timestamp < prev_time) {
|
2014-01-09 18:08:20 -08:00
|
|
|
clear_excess_audio_data(line,
|
2014-01-10 10:55:54 -08:00
|
|
|
prev_time - line->base_timestamp);
|
2014-01-09 18:08:20 -08:00
|
|
|
line->base_timestamp = prev_time;
|
|
|
|
}
|
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
mix_audio_line(audio, line, bytes, prev_time);
|
2014-01-10 10:55:54 -08:00
|
|
|
line->base_timestamp = audio_time;
|
2014-01-09 18:08:20 -08:00
|
|
|
line = next;
|
|
|
|
}
|
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
do_audio_output(audio, prev_time, frames);
|
2014-01-09 18:08:20 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* sample audio 40 times a second */
|
|
|
|
#define AUDIO_WAIT_TIME (1000/40)
|
|
|
|
|
2013-09-30 19:37:13 -07:00
|
|
|
static void *audio_thread(void *param)
|
|
|
|
{
|
|
|
|
struct audio_output *audio = param;
|
2014-01-09 18:08:20 -08:00
|
|
|
uint64_t buffer_time = audio->info.buffer_ms * 1000000;
|
|
|
|
uint64_t prev_time = os_gettime_ns() - buffer_time;
|
|
|
|
uint64_t audio_time;
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
while (event_try(&audio->stop_event) == EAGAIN) {
|
2014-01-09 18:08:20 -08:00
|
|
|
os_sleep_ms(AUDIO_WAIT_TIME);
|
|
|
|
|
|
|
|
pthread_mutex_lock(&audio->line_mutex);
|
|
|
|
|
|
|
|
audio_time = os_gettime_ns() - buffer_time;
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
mix_and_output(audio, audio_time, prev_time);
|
2014-01-09 18:08:20 -08:00
|
|
|
prev_time = audio_time;
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&audio->line_mutex);
|
2013-09-30 19:37:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ------------------------------------------------------------------------- */
|
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
static size_t audio_get_input_idx(audio_t video,
|
|
|
|
void (*callback)(void *param, const struct audio_data *data),
|
|
|
|
void *param)
|
2013-09-30 19:37:13 -07:00
|
|
|
{
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
for (size_t i = 0; i < video->inputs.num; i++) {
|
|
|
|
struct audio_input *input = video->inputs.array+i;
|
|
|
|
if (input->callback == callback && input->param == param)
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
|
|
|
|
return DARRAY_INVALID;
|
|
|
|
}
|
|
|
|
|
2014-01-19 02:16:41 -08:00
|
|
|
void audio_output_connect(audio_t audio,
|
|
|
|
struct audio_convert_info *conversion,
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
void (*callback)(void *param, const struct audio_data *data),
|
|
|
|
void *param)
|
|
|
|
{
|
|
|
|
pthread_mutex_lock(&audio->input_mutex);
|
|
|
|
|
|
|
|
if (audio_get_input_idx(audio, callback, param) != DARRAY_INVALID) {
|
|
|
|
struct audio_input input;
|
|
|
|
input.callback = callback;
|
|
|
|
input.param = param;
|
|
|
|
|
|
|
|
/* TODO: conversion */
|
2014-01-19 02:16:41 -08:00
|
|
|
if (conversion) {
|
|
|
|
input.conversion = *conversion;
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
} else {
|
2014-01-19 02:16:41 -08:00
|
|
|
input.conversion.format = audio->info.format;
|
|
|
|
input.conversion.speakers = audio->info.speakers;
|
|
|
|
input.conversion.samples_per_sec =
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
audio->info.samples_per_sec;
|
|
|
|
}
|
|
|
|
|
|
|
|
da_push_back(audio->inputs, &input);
|
|
|
|
}
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&audio->input_mutex);
|
2013-09-30 19:37:13 -07:00
|
|
|
}
|
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
void audio_output_disconnect(audio_t audio,
|
|
|
|
void (*callback)(void *param, const struct audio_data *data),
|
|
|
|
void *param)
|
2013-09-30 19:37:13 -07:00
|
|
|
{
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
pthread_mutex_lock(&audio->input_mutex);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
size_t idx = audio_get_input_idx(audio, callback, param);
|
|
|
|
if (idx != DARRAY_INVALID)
|
|
|
|
da_erase(audio->inputs, idx);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
pthread_mutex_unlock(&audio->input_mutex);
|
2013-09-30 19:37:13 -07:00
|
|
|
}
|
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
static inline bool valid_audio_params(struct audio_output_info *info)
|
|
|
|
{
|
|
|
|
return info->format && info->name && info->samples_per_sec > 0 &&
|
|
|
|
info->speakers > 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int audio_output_open(audio_t *audio, struct audio_output_info *info)
|
2013-09-30 19:37:13 -07:00
|
|
|
{
|
|
|
|
struct audio_output *out;
|
2014-01-09 18:08:20 -08:00
|
|
|
pthread_mutexattr_t attr;
|
2013-09-30 19:37:13 -07:00
|
|
|
|
|
|
|
if (!valid_audio_params(info))
|
|
|
|
return AUDIO_OUTPUT_INVALIDPARAM;
|
|
|
|
|
|
|
|
out = bmalloc(sizeof(struct audio_output));
|
|
|
|
memset(out, 0, sizeof(struct audio_output));
|
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
memcpy(&out->info, info, sizeof(struct audio_output_info));
|
2013-10-24 00:57:55 -07:00
|
|
|
pthread_mutex_init_value(&out->line_mutex);
|
2014-01-08 15:41:40 -08:00
|
|
|
out->channels = get_audio_channels(info->speakers);
|
|
|
|
out->block_size = out->channels *
|
2013-10-31 10:28:47 -07:00
|
|
|
get_audio_bytes_per_channel(info->format);
|
2013-09-30 19:37:13 -07:00
|
|
|
|
2014-01-09 18:08:20 -08:00
|
|
|
if (pthread_mutexattr_init(&attr) != 0)
|
|
|
|
goto fail;
|
|
|
|
if (pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE) != 0)
|
|
|
|
goto fail;
|
|
|
|
if (pthread_mutex_init(&out->line_mutex, &attr) != 0)
|
2013-09-30 19:37:13 -07:00
|
|
|
goto fail;
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
if (pthread_mutex_init(&out->input_mutex, NULL) != 0)
|
2013-09-30 19:37:13 -07:00
|
|
|
goto fail;
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
if (event_init(&out->stop_event, EVENT_TYPE_MANUAL) != 0)
|
2013-09-30 19:37:13 -07:00
|
|
|
goto fail;
|
|
|
|
if (pthread_create(&out->thread, NULL, audio_thread, out) != 0)
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
out->initialized = true;
|
|
|
|
*audio = out;
|
|
|
|
return AUDIO_OUTPUT_SUCCESS;
|
|
|
|
|
|
|
|
fail:
|
|
|
|
audio_output_close(out);
|
|
|
|
return AUDIO_OUTPUT_FAIL;
|
|
|
|
}
|
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
void audio_output_close(audio_t audio)
|
|
|
|
{
|
|
|
|
void *thread_ret;
|
|
|
|
struct audio_line *line;
|
|
|
|
|
|
|
|
if (!audio)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (audio->initialized) {
|
|
|
|
event_signal(&audio->stop_event);
|
|
|
|
pthread_join(audio->thread, &thread_ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
line = audio->first_line;
|
|
|
|
while (line) {
|
|
|
|
struct audio_line *next = line->next;
|
|
|
|
audio_line_destroy_data(line);
|
|
|
|
line = next;
|
|
|
|
}
|
|
|
|
|
|
|
|
da_free(audio->mix_buffer);
|
|
|
|
da_free(audio->pending_bytes);
|
|
|
|
event_destroy(&audio->stop_event);
|
|
|
|
pthread_mutex_destroy(&audio->line_mutex);
|
|
|
|
bfree(audio);
|
|
|
|
}
|
|
|
|
|
2014-01-09 18:08:20 -08:00
|
|
|
audio_line_t audio_output_createline(audio_t audio, const char *name)
|
2013-09-30 19:37:13 -07:00
|
|
|
{
|
2013-10-24 00:57:55 -07:00
|
|
|
struct audio_line *line = bmalloc(sizeof(struct audio_line));
|
|
|
|
memset(line, 0, sizeof(struct audio_line));
|
|
|
|
line->alive = true;
|
2014-01-09 21:04:25 -08:00
|
|
|
line->audio = audio;
|
2013-10-24 00:57:55 -07:00
|
|
|
|
2014-01-09 18:08:20 -08:00
|
|
|
if (pthread_mutex_init(&line->mutex, NULL) != 0) {
|
|
|
|
blog(LOG_ERROR, "audio_output_createline: Failed to create "
|
|
|
|
"mutex");
|
|
|
|
bfree(line);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-10-24 00:57:55 -07:00
|
|
|
pthread_mutex_lock(&audio->line_mutex);
|
2014-01-09 18:08:20 -08:00
|
|
|
|
|
|
|
if (audio->first_line) {
|
|
|
|
audio->first_line->prev_next = &line->next;
|
|
|
|
line->next = audio->first_line;
|
|
|
|
}
|
|
|
|
|
|
|
|
line->prev_next = &audio->first_line;
|
|
|
|
audio->first_line = line;
|
|
|
|
|
2013-10-24 00:57:55 -07:00
|
|
|
pthread_mutex_unlock(&audio->line_mutex);
|
2014-01-09 18:08:20 -08:00
|
|
|
|
|
|
|
line->name = bstrdup(name ? name : "(unnamed audio line)");
|
2013-10-24 00:57:55 -07:00
|
|
|
return line;
|
|
|
|
}
|
|
|
|
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
const struct audio_output_info *audio_output_getinfo(audio_t audio)
|
2013-10-24 00:57:55 -07:00
|
|
|
{
|
|
|
|
return &audio->info;
|
2013-09-30 19:37:13 -07:00
|
|
|
}
|
|
|
|
|
2013-10-24 00:57:55 -07:00
|
|
|
void audio_line_destroy(struct audio_line *line)
|
|
|
|
{
|
|
|
|
if (line) {
|
|
|
|
if (!line->buffer.size)
|
|
|
|
audio_output_removeline(line->audio, line);
|
|
|
|
else
|
|
|
|
line->alive = false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t audio_output_blocksize(audio_t audio)
|
|
|
|
{
|
|
|
|
return audio->block_size;
|
|
|
|
}
|
|
|
|
|
2014-01-08 15:41:40 -08:00
|
|
|
static inline void mul_vol_u8bit(struct audio_line *line, float volume,
|
|
|
|
size_t total_num)
|
|
|
|
{
|
|
|
|
uint8_t *vals = line->volume_buffer.array;
|
|
|
|
int16_t vol = (int16_t)(volume * 127.0f);
|
|
|
|
|
|
|
|
for (size_t i = 0; i < total_num; i++) {
|
|
|
|
int16_t val = (int16_t)(vals[i] ^ 0x80) << 8;
|
|
|
|
vals[i] = (uint8_t)((val * vol / 127) + 128);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void mul_vol_16bit(struct audio_line *line, float volume,
|
|
|
|
size_t total_num)
|
|
|
|
{
|
|
|
|
uint16_t *vals = (uint16_t*)line->volume_buffer.array;
|
|
|
|
int32_t vol = (int32_t)(volume * 32767.0f);
|
|
|
|
|
|
|
|
for (size_t i = 0; i < total_num; i++)
|
|
|
|
vals[i] = (int32_t)((int32_t)vals[i] * vol / 32767);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline float conv_24bit_to_float(uint8_t *vals)
|
|
|
|
{
|
|
|
|
int32_t val = ((int32_t)vals[0]) |
|
|
|
|
((int32_t)vals[1] << 8) |
|
|
|
|
((int32_t)vals[2] << 16);
|
|
|
|
|
|
|
|
if ((val & 0x800000) != 0)
|
|
|
|
val |= 0xFF000000;
|
|
|
|
|
|
|
|
return (float)val / 8388607.0f;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void conv_float_to_24bit(float fval, uint8_t *vals)
|
|
|
|
{
|
|
|
|
int32_t val = (int32_t)(fval * 8388607.0f);
|
|
|
|
vals[0] = (val) & 0xFF;
|
|
|
|
vals[1] = (val >> 8) & 0xFF;
|
|
|
|
vals[2] = (val >> 16) & 0xFF;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void mul_vol_24bit(struct audio_line *line, float volume,
|
|
|
|
size_t total_num)
|
|
|
|
{
|
|
|
|
uint8_t *vals = line->volume_buffer.array;
|
|
|
|
|
|
|
|
for (size_t i = 0; i < total_num; i++) {
|
|
|
|
float val = conv_24bit_to_float(vals) * volume;
|
|
|
|
conv_float_to_24bit(val, vals);
|
|
|
|
vals += 3;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void mul_vol_32bit(struct audio_line *line, float volume,
|
|
|
|
size_t total_num)
|
|
|
|
{
|
|
|
|
int32_t *vals = (int32_t*)line->volume_buffer.array;
|
|
|
|
|
|
|
|
for (size_t i = 0; i < total_num; i++) {
|
|
|
|
float val = (float)vals[i] / 2147483647.0f;
|
|
|
|
vals[i] = (int32_t)(val * volume / 2147483647.0f);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void mul_vol_float(struct audio_line *line, float volume,
|
|
|
|
size_t total_num)
|
|
|
|
{
|
|
|
|
float *vals = (float*)line->volume_buffer.array;
|
|
|
|
|
|
|
|
for (size_t i = 0; i < total_num; i++)
|
|
|
|
vals[i] *= volume;
|
|
|
|
}
|
|
|
|
|
2014-01-10 18:03:21 -08:00
|
|
|
static void audio_line_place_data_pos(struct audio_line *line,
|
2014-01-08 15:41:40 -08:00
|
|
|
const struct audio_data *data, size_t position)
|
|
|
|
{
|
|
|
|
size_t total_num = data->frames * line->audio->channels;
|
2014-01-09 21:04:25 -08:00
|
|
|
size_t total_size = data->frames * line->audio->block_size;
|
2014-01-08 15:41:40 -08:00
|
|
|
|
|
|
|
da_copy_array(line->volume_buffer, data->data, total_size);
|
|
|
|
|
|
|
|
switch (line->audio->info.format) {
|
|
|
|
case AUDIO_FORMAT_U8BIT:
|
|
|
|
mul_vol_u8bit(line, data->volume, total_num);
|
|
|
|
break;
|
|
|
|
case AUDIO_FORMAT_16BIT:
|
|
|
|
mul_vol_16bit(line, data->volume, total_num);
|
|
|
|
break;
|
|
|
|
case AUDIO_FORMAT_32BIT:
|
|
|
|
mul_vol_32bit(line, data->volume, total_num);
|
|
|
|
break;
|
|
|
|
case AUDIO_FORMAT_FLOAT:
|
|
|
|
mul_vol_float(line, data->volume, total_num);
|
|
|
|
break;
|
|
|
|
case AUDIO_FORMAT_UNKNOWN:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
circlebuf_place(&line->buffer, position, line->volume_buffer.array,
|
|
|
|
total_size);
|
|
|
|
}
|
|
|
|
|
2014-01-10 18:03:21 -08:00
|
|
|
static inline void audio_line_place_data(struct audio_line *line,
|
|
|
|
const struct audio_data *data)
|
|
|
|
{
|
|
|
|
uint64_t time_offset = data->timestamp - line->base_timestamp;
|
Simplify media i/o interfaces
Completely revamped the entire media i/o data and handlers. The
original idea was to have a system that would have connecting media
inputs and outputs, but at a certain point I realized that this was an
unnecessary complexity for what we wanted to do. (Also, it reminded me
of directshow filters, and I HATE directshow with a passion, and
wouldn't wish it upon my greatest enemy)
Now, audio/video outputs are connected to directly, with better callback
handlers, and will eventually have the ability to automatically handle
conversions such as 4:4:4 to 4:2:0 when connecting to an input that uses
them. Doing this will allow the video/audio i/o handlers to also
prevent duplicate conversion, as well as make it easier/simple to use.
My true goal for this is to make output and encoder plugins as simple to
create as possible. I want to be able to be able to create an output
plugin with almost no real hassle of having to worry about image
conversions, media inputs/outputs, etc. A plugin developer shouldn't
have to handle that sort of stuff when he/she doesn't really need to.
Plugins will be able to simply create a callback via obs_video() and/or
obs_audio(), and they will automatically receive the audio/video data in
the formats requested via a simple callback, without needing to do
almost anything else at all.
2014-01-14 00:58:47 -08:00
|
|
|
size_t pos = time_to_bytes(line->audio, time_offset);
|
2014-01-10 18:03:21 -08:00
|
|
|
|
|
|
|
audio_line_place_data_pos(line, data, pos);
|
|
|
|
}
|
|
|
|
|
2013-10-24 00:57:55 -07:00
|
|
|
void audio_line_output(audio_line_t line, const struct audio_data *data)
|
|
|
|
{
|
2014-01-09 18:08:20 -08:00
|
|
|
/* TODO: prevent insertation of data too far away from expected
|
|
|
|
* audio timing */
|
|
|
|
|
|
|
|
pthread_mutex_lock(&line->mutex);
|
|
|
|
|
2013-10-24 00:57:55 -07:00
|
|
|
if (!line->buffer.size) {
|
|
|
|
line->base_timestamp = data->timestamp;
|
2014-01-10 18:03:21 -08:00
|
|
|
audio_line_place_data_pos(line, data, 0);
|
2013-10-24 00:57:55 -07:00
|
|
|
|
2014-01-10 18:21:32 -08:00
|
|
|
} else if (line->base_timestamp <= data->timestamp) {
|
|
|
|
audio_line_place_data(line, data);
|
|
|
|
|
|
|
|
} else {
|
|
|
|
blog(LOG_DEBUG, "Bad timestamp for audio line '%s', "
|
|
|
|
"data->timestamp: %llu, "
|
|
|
|
"line->base_timestamp: %llu. This can "
|
|
|
|
"sometimes happen when there's a pause in "
|
|
|
|
"the threads.", line->name, data->timestamp,
|
|
|
|
line->base_timestamp);
|
2013-10-24 00:57:55 -07:00
|
|
|
}
|
2014-01-09 18:08:20 -08:00
|
|
|
|
|
|
|
pthread_mutex_unlock(&line->mutex);
|
2013-10-24 00:57:55 -07:00
|
|
|
}
|