Hi there, we’re now in the last part of the summer.
A lot happened in the UltraDV source. The code is gradually maturing and a lot of components have been replaced and implemented among more than 30 commits.
Someone might have already noticed there’s some ferment around UltraDV, originally supposed to be a BeOS killer app then it stalled down. It was finally open sourced under MIT license around 2013 and today we are trying to find a path to see it’s development continue. Today I’m going to show the good points as well as the hard ones.
Let’s talk about the most recent improvements in streaming support, this is perhaps a bit more technical than in past but in this case most of the work was related to refine internal mechanisms. I’m going to talk also about recent MediaPlayer changes, as well as other things.
Finally a new report. The time since the latest report has been spent mostly into gaining a preliminary support to streaming and begin finalyzing the underlying support code.
This included documenting myself about the APIs and figuring out how to implement the functionality in a clean way. There are various additions, we are moving to the right place so we finally have a streaming infrastructure.
It’s really a long time since the latest report, starting with this one I’m going to restore the usual article frequency.
The second part of my contract has been accepted and I’m finally returning to work on streaming support. However there is various work I had not the possibility to talk about and other things I pushed in the last week.
Good news everyone!
It was a very long week, having easter in the middle too. There are various news, but I want to begin with a summary of this month.
- 42 commits have been included into the Haiku master branch
- More than 15 commits are still WIP among my branches
- 2 commits have been put into haikuports
- 4 tickets are now closed and a lot more are waiting my work to be complete
I submitted a request to Haiku Inc. to work for additional 240 hours, and I hope the project gets the needed funding to support my work. If you are interested in seeing my contract continue, please consider making a donation :-)
Let’s talk about what happened in the meantime.
Hello, here a short report about how things are coming along.
Work continue on the curl streaming code
I’ve continued working on the network glue by adding a very basic locking using the RWLocker in Haiku’s shared kit. This class allow multiple concurrent readers and an exclusive writer at one time.
there are not a lot of news. This is mostly due to myself being occupied in the lastest two weeks with other commitments that I can’t really avoid. The situation is going to change, and I plan to restore a normal working day since monday.
The hours in the latest week have been put in the development of the streaming infrastructure. Plugins are now correctly loaded by the app, and the internal classes now provide the needed exceptions to consider network streams. I’ve had to do some step back into the API desing reconsidering more carefully the caching policies offered to the final program.
Hello, as you may have seen from the news on the front page of the website, the contract I proposed has been accepted. This contract relates to development in the media_kit area. While there is more than one goal, the first part will be dealing with streaming support. I would like to thank all the donors that made this contract possible.
The first week has been something like slow start; I expect to spend an increasing number of hours the more I get into the contract. As the official announcement hinted this is an initial contract for 120 hours. My intention is to get the media_kit in good shape to eventually concentrate on other things. The tasks I put into my contract proposal are important for more than one reason:
Hello, it has been some time since my last article, in the meantime I continued to improve things out and since I changed some important parts of the media_kit, I think it’s correct to notify the community about new and ‘old’ features added recently. This is an article mostly written for application developers, but I tried to explain the improvements made with simple words so I hope it will be interesting to anyone.
With the advent of package management and hrev46391, it has become possible to prevent a package from being extracted at boot time.From a suggestion of Matt, and with the contribution of Luroh (thanks!), i would like to explain you how to blacklist a package file in Haiku.
In Haiku’s boot menu , there is a ‘Blacklist entries’ option available. This method will only let you disable system packages, and only until the next time you reboot.
Hello, it has been passed some time from the Part 1 of this article, I’ve continued my investigations as well, and I have finally some more clear plans for such a hypotetic Jack2 port. Unfortunately i had not enough time to research a bit more in the latency differences between the media_kit and jack, sorry, this should be post-poned until i have precise emphyrical measuring methods.
To better understand this article i suggest you to read the first part.
In the last year i managed to play a bit more with the Haiku media_kit. It was already discussed in various places if jack2 should be adopted, ported, or someway integrated into Haiku. There are various opinions out there, and more or less going down into the topic i want to show you what i think about.
Jack2 is a real-time audio server for UNIX systems, to be more specifical a smp focused reimplementation of Jack (which is single-threaded), it provides a protocol used by audio apps for inter-communication.
In some situations, for example when we are using linux, can be extremely annoying to reboot into Haiku every time we need something (for example when we have a ppp connection).
I’ve written this article and i decided to post it here, in the hope that will help users and developers to have the life a bit simple.
There’s a fast method to boot a physical Haiku partition using VirtualBox, it require only a few commands.
You probably know that i have not passed the GSoC final evaluation. Although i am a bit discouraged (it’s natural i think), as said from the begin, it’s not my intention to abandon my project. Money wasn’t my first motivation to work, and it will not be in any case.
It’s just a short post to tell you what is the state of my code, and about which i’m working on.
In these weeks i have improved the contacts kit core in order to have enough support for the formats supported. The vcard and people translators can now translate and exchange many types of field, though photo and groups aren’t yet supported.
Main functionalities of the classes : BRawContact Their functionality is to deal with the BTranslatorRoster and keep track of basic informations, like the final format. The final destination is represented as a BPositionIO object.
From my latest post, i had to do more work on the base classes, i realized that my implementation of BContactField was too inflexible for the use so my progresses were not fast as i hoped. The main problem was to provide something that can fit the simplicity of the Person format (people files) and the complexity of VCard. The result was BContactField. Starting from a number of fields (defined in ContactDefs.
These weeks were prolific in terms of design and experiments but due to university commitments i am a bit late with the expected goals. At this point i have an implementation of BContact / BRawContact and i’m working to get the VCard translator functional. In these hours my focus is the communication part between the raw contacts and translators.
One of the latest design decisions was to make BRawContact own a translator that is suitable for writing the format specified by the user, otherwise it will use the default B_CONTACT_FORMAT (a flattened BMessage) for the final file.
During the community bonding period, i have researched around the project to prepare my work for the coding days that will follow. I also promised to talk with the other devs in the ml, it was not necessary in these days…i’m working with the help of Alex to a document describing the entire API in order to discuss it in the ml.
The first problem was to choose a Default Media Format for contact translators, my choice has been addressed to a flattened BMessage.
Unlike most students i’m not new to Haiku, i’ve already contributed around the Haiku community, maybe you can remember me for my work on Caya (msn plugin). Not by chance my gsoc project is somehow related to Caya (and every app that expose contacts).
The fundamental idea is to provide a core set of classes with the aim of contacts integration into the system. The basic idea around the entire project is fairly simple in theory : The api should be easily extendable.