Welcome to the second monthly report for 2018!
This report covers hrev51791-hrev51832
There is a lot of invisible work in progress on getting the Haiku infrastructure
migrated to a new server and streamlined to use containers and standardized setup.
This will eventually allow to better share the work of system administration in
a larger team, allowing to scale up the infrastructure.
This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/pulkomandy/2018-03-04_haiku_monthly_activity_report_february_2018/
Much thanks (and I probably speak for the community) to whomever got system updates working again, great job!
Just a little note. It’s not really a question of the media client not being low level. I’m designing this class to be able to do the same things (and more) you can do with a media node. The main improvement is allowing nodes to reuse as much code as possible and allowing a full OOP API. I think I will explain things more in detail when I feel the API is done.
BTW I’m planning to introduce a BMediaClient derivative called BAudioUnit…
Hey, @Barrett, I’ve been watching your work and keep on seeing your mention BMediaGraph, what will that class be planned to do?
If I remember correctly new infrastructure will get Haiku closer to beta, so I`m glad that this process is moving forward.
After the address space protection changes for the kernel memory are finished, it might Be an interesting exercise to compile & run the latest Wine 3 on Haiku to see if anything has changed compatibility-wise - compared to running Wine 2 on the previous memory address space layout.
And maybe the WineHQ Haiku compatability page could be updated with the results, for people who are interested in tackling some of the problems and getting Wine to work.
We have not changed the memory layout. We have just added extra protection to make sure a malicious or broken app does not make the kernel overwrite its own data accidentally. This does not help with getting Wine running.
sad news here it should be hard to do.
AFAIK x86_64 don’t need any layout changes. X86 needs, but that would break the BeOS compatibility, so no-go.
Basically the idea is that the internal processing path can be described using a graph.
In my opinion one of the main issue with the media kit API design is that it’s too focused on nodes. In reality, the center of the problem are the node input/outputs and their relationships, both internal and external. This class is aimed to solve the problem of assigning resources to inputs and outputs in a way that can be easily described using a graph.
Once this is in place we can begin to think about more smart ways of managing latencies that can be easily predictable. The synchronization of inputs and outputs can be easily described in a way that allow maximizing the use of resources.
Then there should be a port for x64, thats are the kind of things why i am using the x64 version i prefer modern Porta and software than oldies… Is personal anyway.
Then just port that thing! And do not forget to create a PR.