Gerrit Submission.
Check out my final Pull Request here: 8141
Overview
During this GSoC period, I focused on developing the virtio sound driver for Haiku,
aiming to enhance its performance as a guest OS in virtualized environments.
This journey began with some challenges, for example, initially, I missed a small
detail in the driver module path, which prevented the driver from loading.
One of the significant setbacks, I had, was understanding hmulti_audio.
With little to no documentation available, it felt like working with a black box.
I had to dive into existing audio drivers to piece together how things worked, but
even then, some aspects remained hidden to me.
intro
Hello, once again!
vid?
We made it! I previously stated that we had achieved playback,
but I never got to show it. So here it is, a short video
showing you that playback actually works.
So you don’t have to go and compile it, just to see it on
action.
outro
Main functionality is here! So, I believe that it may be
time to maybe push into the main branch.
intro
Hello, once again! It’s been weeks since the last update, so here we go.
Good news, there is active development of the virtio sound driver for Haiku.
Key progress includes recording on the device and improvements.
buffer exchange redesign
As per the last blog post:
We still specify 2 playback buffers, but incremented to 16,384 frames per
buffer, to handle audio streams.
struct multi_buffer_info {
// [...]
bigtime_t played_real_time;
bigtime_t played_frames_count;
// [...]
int32 playback_buffer_cycle;
bigtime_t recorded_real_time;
bigtime_t recorded_frames_count;
// [...]
int32 record_buffer_cycle;
// [...]
};
I messed up a lot during these last two weeks. A certain bug
appeared, and it was a tricky one, not even appearing all the time. As far
as I’m concerned, it looks like I should not have gone playback-first and
recording-last.
intro
Hello, once again! It’s been three weeks since the last update, so here we go.
Good news, there is active development of the virtio sound driver for Haiku.
Key progress includes achieving playback on the device.
Getting the buffers ready.
We need to tell hmulti_audio where it should expect to write and read the audio
frames, to do that we need to fill out a structure called multi_buffer_list:
struct multi_buffer_list {
// [...]
int32 return_playback_buffers;
int32 return_playback_channels;
uint32 return_playback_buffer_size;
// Contains the pointer to the start of a given buffer,
// as well as the stride it should take.
buffer_desc ** playback_buffers;
// [...]
int32 return_record_buffers;
int32 return_record_channels;
uint32 return_record_buffer_size;
buffer_desc ** record_buffers;
// [...]
};
We currently specify 2 playback buffers, 1024 frames per buffer, to handle
audio streams. The number of channels is specified in the chmap_query or
defaulting to stereo if no channel maps are given by the device.
intro
Hello, once again! It’s been a month since the last update, so here we go.
Good news, there is active development of the virtio sound driver for Haiku.
Key progress includes assigning channel maps to their respective streams and
integrating PCM stream scanning.
Additionally, efforts have focused on modularizing the driver, ensuring
compliance with Haiku’s coding standards, and laying the groundwork for further
enhancements to functionality. While progress has been substantial, there are
still areas requiring refinement as we continue to expand the driver’s
capabilities.
short whoami
Hello! I’m Diego Roux, an undergraduate engineering student at Universidad
Iberoamericana (Mexico). Passionate about low-level stuff, OS/kernel dev,
embed libs, and more!
I’m grateful to be working under Haiku for this GSoC! So, I’ll be working
to add support for sound virtio, enhancing virtualization by working with
the VM.
I’ll be under the guidance of
@Korli. Thanks! :D
brief intro + my plans
Whenever we boot a VM with Haiku in it, it needs to ensure we have a proper
environment, emulating all physical devices we require (e.g. ethernet, sound,
video, graphics, etc); great, isn’t it? we have everything nearly as we
would on actual hardware, but as with all great things in life, this comes
with a downside, emulation is (for our purposes) computationally expensive
(not really, but it does add some unnecessary overhead).
