DVB coming to Haiku

In August 2005 I had some major disagreement with Bernd Korz, former CEO of YellowTab, the company that was developing and selling Zeta. Zeta was meant to be successor of BeOS R5. Since a few weeks, it looks like Zeta is dead and won't be continued.

I very much believe that Haiku is becoming the only replacement and successor of BeOS R5 now. It's already very useable, and can run a variety of BeOS R5 Applications, like for example Wonderbrush.

It's was in July 2005 when I finished the first useable package of DVB-T support for BeOS. Later I dropped supporting it because of the problems described above. But guess what, the BeOS R5 DVB-T package already runs on Haiku, too.

Compared to BeOS, Haiku is still lacking a live TV input. BeOS R5 included a driver for BT878 analogous TV, Haiku as of today hasn't one. I don't have any analogous TV anymore, so I can't change that.

I've therefore decided that I'll do a checkin of my DVB-T sources into the Haiku source tree. Including driver, media-add-on and TV application. The audio and video codecs that I used with BeOS and Zeta will not be included. Haiku allready has all required codecs. This means some porting work after the initial checkin, to utilize the Haiku media kit in the way it's meant to be used. DVB will then use the Haiku codecs by means of the BMediaDecoder class.

It might be possible to get DVB-S support (Skystar 2 card) for Haiku in the future, by means of a third party driver. However, this is undecided so far.

Serial ATA support for AHCI devices, as mentioned in a blog posting in January is still beeing worked on.

I managed to find a few old screenshots from DVB-T on BeOS, it will look simlar on Haiku.

Screenshot 1
Screenshot 2
Screenshot 3
Screenshot 4

(The screenshots were done utilizing two DVB-T cards)

Eight Students to Code for Haiku at GSoC 2007

As just announced at haiku-os.org eight students will work on Haiku projects during the summer.

The following topics will be covered:

• Network stack revamp: IPv6, ICMP, multicast, etc.


• Create a thread scheduler with CPU affinity


• USB isochronous streams


• FireWire stack for Haiku


• Network Preferences Application


• Package (.pkg) installer for the Haiku Operating System


• Implement ICMP error handling and propagation


• Implement a precache algorithm along with aging policy for the file system caches

Zeta dead, summary of most interesting quotes

Some interesting quotes in chronological order:

(Update: I'm added translations of the german texts)

March 23rd, 2007, Bernd Korz himself berndsworld.com

"Ich gebe heute offiziell bekannt, dass es keinerlei Zusammenarbeit zwischen mir und der Magnussoft mehr gibt. Gleiches gilt für alle Entwickler für das Projekt ZETA die von Magnussoft bezahlt wurden und mit mir gemeinsam daran gearbeitet haben.

Da sich am Team selbst nichts geändert hat arbeiten, wir derzeit in selbem Tempo weiter. Das Update werde ich wie publiziert in Kürze herausgeben."

Translation:
I announce today officially that there is no further co-operation between me and Magnussoft. The same applies to all developers to the project ZETA that were paid by MAgnussoft and worked with me together on it.

Since the team itself did not change, we continue to work at present with same speed. As announced, the update will be published shortly.


Montag 26 Maerz 2007 - 16:17:28, magnussoft Deutschland zeta-os.com

"[...] Dieses Bekenntnis untermauerte magnussoft Deutschland im letzten Jahr mit dem Abschluss eines exklusiven Vertriebsvertrages mit Herrn Bernd Korz sowie mit der Bereitstellung und Finanzierung eines speziellen Entwicklerteams für magnussoft® Zeta.

[...] wurde die Finanzierung des Entwicklerteams durch magnussoft® zum 16.03.2007 bis auf weiteres eingestellt.

Hiervon unberührt bleibt die Tätigkeit von magnussoft Deutschland als exklusiver Distributor für magnussoft® Zeta. Die entsprechenden vertraglichen Vereinbarungen sehen dies zunächst bis Ende 2007 vor.

Magnussoft® Deutschland ist auch über diesen Zeitpunkt hinaus an dem Fortbestand von magnussoft® Zeta interessiert. Hierzu werden in der nächsten Zeit Gespräche geführt. [...]"

Translation:
[...] This confession did Magnussoft support in the last year with the conclusion of an exclusive selling contract with Mr. Bernd Korz as well as with the supply and financing of a special developer team for magnussoft® Zeta.

[...] the financing of the developer team was stopped until further notice through magnussoft® to 16.03.2007.

The activity of magnussoft Germany as distributor remains unaffected by this. The appropriate contractual agreements support this to the end of 2007.

Magnussoft® Germany is also beyond this time interested in the continuation of magnussoft® Zeta. For this very soon negotiations will be made. [...]



March 27th, 2007, Bernd Korz himself berndsworld.com comments

Bernd on 27.03.2007 at 08:14

Ich weiss nichts von irgendwelchen Verhandlungen.

Translation: I'm not aware of any negotiations


April 2nd, 2007, Bernd Korz himself berndsworld.com

"In den letzten 11 Monaten ist vieles an ZETA passiert und wir konnten ein gutes Stück vorankommen. [...]

Ich werde offiziell die Weiterentwicklung an ZETA einstellen. Ob und wie ich die Sachen opensource stellen werde oder für Haiku zugänglich mache, kann ich zu diesem Zeitpunkt noch nicht sagen. [...]

Zurzeit hat weder die yellowTAB noch die Magnussoft Zugriff auf die Sourcen, dies wird auch bis auf weiteres so bleiben. Sollte sich hier was ändern, so werden beide Parteien das sicherlich selbst publizieren können. Was mich angeht, so wird sich an dieser Tatsache aber auch in Naher Zukunft nichts ändern. Weder sehe ich mich dazu veranlasst noch haben die einzelnen Entwickler einen Wunsch in diese Richtung geäussert. [...]

Frans, is there something to say? Not really :) You made ZETAs Kernel running smooth and did so much beside that for ZETA."

Translation:
“During the last 11 months much work has been done at ZETA and we could advance a lot. [...]

I will stop officially further development at ZETA. Whether and how I will provide the things as open source or will make them accessible for Haiku, I cannot say at this time. [...]

At the moment, neither yellowTAB nor Magnussoft has access to the source code, this will persist until further notice. Should something regarding this change, then both parties will surely be able to publish that. As far as I am concerned, in the near future nothing will change. Neither do I see the need, neither have individual developers expressed a desire. [...]

Frans, is there something to say? Not really :) You made ZETAs Kernel running smooth and did so much beside that for ZETA."



2007-04-04 00:36:15, David "Lefty" Schlesinger, Director, Open Source Technologies, ACCESS Co., Ltd., bitsofnews.com

"I'd like to correct a major misstatement here: Zeta is not, nor has it ever been, a licensee of PalmSource (or ACCESS, the company which acquired PalmSource year before last) in any way, shape or form. If Zeta or magnussoft has claimed that they have a license with us, that's a complete falsehood.

As the legitimate owners of the intellectual property formerly belonging to Be, our position is that the product marketed by YellowTab and then by magnussoft represents a pirated version of BeOS, done without our permission or approval.

magnussoft is thus in no position to open source anything, since their product, in its entirety, represents a derivative work of our intellectual property."

4. April 2007 um 17:02, golem.de quoting a response received from Bernd Korz, golem.de

"[...] da dies außerhalb meines Kenntnissstandes liegt. Die YellowTab ist, wie Sie wissen, insolvent und wird durch einen Insolvenzverwalter vertreten. Ich selbst bin in keinster Weise mehr involviert, seit nunmehr fast zwölf Monaten. Ebenso liegt mir keinerlei Schriftverkehr diesbezüglich vor"

Translation: [...] since this matters stand outside of my state of knowledge. The YellowTab is insolvent, as you know, and represented by an insolvency manager. I am not involved in any way any more, since nearly the last twelve months. Likewise I do not have any correspondence regarding this topic.


2007-04-05 08:58:13, David "Lefty" Schlesinger, Director, Open Source Technologies, ACCESS Co., Ltd., osnews.com forum

"I further note that, earlier today, having been unable to locate an email address for Mr. Korz, I posted a comment to his latest blog entry asking that he--while he's waiting for his lawyer to free up an hour--provide me with a copy of the license he claims allows him to produce and market Zeta. The comment, initially "marked for moderation", was promptly deleted. Perhaps unsurprisingly, I've had no word from Mr. Korz in response to my request.

Evidently Mr. Korz is not only uninterested in talking to me, he's equally uninterested in talking to his (ex-)distributor's lawyer. Presumably, he realized some income from sales of Zeta; even with the severing of the relationship between Mr. Korz and Magnussoft, one would have to assume--if he indeed had some legitimate support for his claims--that he'd have some degree of interest in producing it for them."

05 April 2007 - 17:09:12, magnussoft Deutschland, zeta-os.com

"We immediately approached our licenser for clarification of the legal position. Mr. Korz stated towards our lawyer that he would not be interested in cooperating with magnussoft Deutschland in this matter.

Magnussoft is not in a position to judge the statement of Access Co. Ltd. We do not have any notice of potential contracts or arrangements between Mr. Korz and the legal owner(s) of the BeOS source-code. Due to this legal uncertainty we decided to cease distribution of Zeta."

Zeta watch, report of Febuary 13th

News from Magnussoft? No.

Their website still states the same facts as two weeks ago on availability of Zeta 1.5. On January 30th, it was supposed to be delivered to distributors "Ende nächster Woche", that makes the past weekend. So it should be available right now. Their webshop still hasn't been updated. They are still announcing an expected release date of January 29th.

You are going to order it anyway, because it's well supported high quality software, correct?

Zeta Vista

It's odd. Windows Vista was available from retail channes on January 30th, 2007. Magnussoft Zeta 1.5 was initally announced to be available on January 15th, 2007, but then got postponed to January 29th. One day prior to vista.

I've seen Vista advertisements at prime time on TV yesterday. Magnussoft of cause probably doesn't want to burn their venture capital on TV adverstisements. So let's have a look what their homepage, today on January 31th, has to offer.

The frontpage is still offering Zeta 1.21. You can only get 1.5 as an upgrade, and there is a news item about the 1.5 upgrade beeing pushed to the press shop during this week. It also says that delivery to retail channels will start end of next week, that makes February 9th.

When visiting their online shop, you are still told that Zeta 1.5 upgrade is expected to be released on January 29th, and that you can only preorder.

I don't know why Magnussoft is unable to cleanup that confusing mess, but here is a summary of the current state: You can't buy Magnussoft Zeta 1.5 at the moment. You also won't be able to buy Magnussoft Zeta 1.5 without prior owning a Magnussoft Zeta 1.21, because it's only an upgrade. This is bad for those who wanted to purchase a full version of Zeta 1.5, but probably good for shops that overstocked 1.21.

I don't own Zeta 1.21. And I'm not going to buy Vista.

Haiku AHCI support

What does that mean? AHCI is the greatest thing since sliced bread. One interface to rule them all. One interface to find them. Them SATA harddisks.

Serial-ATA host controllers manufactured during the last two years are all slightly different, from the programming interface side of view. You need an extra driver for every one of them.

Intel decided time was ready for a generic standard, and invented AHCI, the Advanced Host Controller Interface. The specification was published in 2004 and you can get motherboard featuring those controllers right now.

I recently bought an Asus P5W DH Deluxe motherboard, which features the Intel 975X (ICH7R) chipset. Additionally, it uses an Jmicron JMB363 controller, which is also AHCI compliant. There is also a Hardware RAID controller Silicon Image 4723 included, but I'm not using it. It offers real hardware RAID (no driver required, you have to use a jumper to select the RAID mode) but as there is only Windows software available to be notified about RAID failure. For me it doesn't make much sense to utilize it, as at the moment I'm only running Linux at this computer.

I'm using Linux for Haiku development, and have setup the crosscompilation environment. Once the AHCI driver is ready (or when I decide to add an additional PATA harddisk), it will be possible to run Haiku on this machine.

On this website, Intel lists the following chipsets as AHCI compliant:

Intel® 631xESB/632xESB I/O Controller Hub
Intel® 82801HR/HH/HO I/O Controller Hub (ICH8R)
Intel® 82801GBM I/O Controller Hub (ICH7M)
Intel® 82801GR I/O Controller Hub (ICH7R)
Intel® 82801GH I/O Controller Hub (ICH7DH)
Intel® 82801FR I/O Controller Hub (ICH6R)
Intel® 82801FBM I/O Controller Hub (ICH6M)

Long time no see

Welcome back fellow readers!

It's 2007 already, that means more than one year without a post. You are probably wondering what happened. Well, a lot of things did, so I'm not going into details.

Most importantly, YellowTab decided that they wouldn't sue me. In April 2006, YellowTab went bankrupt.

Shortly after, I even met Bernd Korz at the Begeistert meeting, and he appologized for sending that mail. I accepted his apology, but this doesn't mean we'll have any future business relations .

Today, Magnussoft is selling Zeta. Mr Korz is now also working there. I don't know how, but there must have been a lawful method for transfering the sourcecode and whatever they needed from YellowTab to Magnussoft.

The new Magnussoft Zeta can already be preordered and was initially announced to be ready at January 15th, 2007. Yesterday (on January 17th), they announced a delay to January 29th.

I'm continuing work on the Haiku project, which is a BeOS R5 clone.

Right now I'm adding AHCI support.

Threatening mail by Yellowtab

Update 2005-08-20, 14:53:

The comments in the german BeOS user group website forums that are linked in the update below have been deleted by Ralf Schülke, an other admin of that website. They have NOT been deleted by Bernd Korz. Ralf Schülke said in chat that he did this in order to keep the website clean, and due to (but not on behalf of) the person who posted those comments. Quote: "das die debug solange wie ich da was entscheiden kann, auch sauber bleibt" and "er macht nur Ärger".

Update 2005-08-20, 14:16:

Nothing related to AVM, ISDN, DVB-T or SATA development that is described in this blog is covered by a NDA signed with Yellowtab. In his email, Bernd Korz refers to another incidence that is unrelated to this blog, when threatening to sue me after he got angry about the AVM article I wrote.

Bernd Korz is admin of the german BeOS user group website, and of cause the Yellowtab.com and Yellowtab.de websites. Multiple comments posted there, which tried to link to this blog, have been deleted. Some of them are mirrored here:

My original posting in the Yellowtab.de forum AVM thread (HTML)
One posting in the Beusergroup.de forum (image)
A new thread in the Beusergroup.de forum (image)


Original article 2005-08-19, 20:28:

After I read the third comment to the previous blog posting yesterday morning, I was fairly sure that it had been posted by Bernd Korz, the one mentioned in the article. The comment is the one that starts with "One of that projects you started and never finished. Well you are such a person." The phrases used, typical spelling mistakes, background knowledge that shows through, omission of facts, date and time of posting, etc. everything seemed to indicate that it was written by him. Judging other comments and responses, many people assume the same. I wasn't sure if it was really him, because I thought that he wouldn't be so mad at me to do such a nutty thing like posting the comment.

I didn't contact him, and I didn't ask. But I noticed that the single comment as pointer to the blog article, that I had left in the original thread at Yellowtab forum, had been deleted at about the same time.

Well, yesterday evening I recieved an outrageous email from Yellowtab, written by their CEO/CVO Bernd Korz. Now I'm even more sad about Yellowtab's behaviour. Threatening me in such a perfidious way, while at the same time selling Zeta, which contains drivers that I wrote for BeOS and were available free of charge.

At the beginning of the mail, he denies to have written the comment in my blog. Then he acknowledges to have deleted my comment in the Yellowtab Forum. He goes on by explaining that he had to pay for the hardware that AVM provided. After that, he says that he has no interest in what I do, write or post, and that he doesn't want to deal with me anymore, pretending to speak for all Yellowtab developers.

Now the ugly part starts. Using an alleged NDA (non disclosure agreement) breach, he promises to undertake everything that is possible to sue me. He claimes that even this mail is protected by the NDA that I signed with Yellowtab, but I'm certain that it doesn't apply here. At the end, he says that a copy of that mail was sent to their lawyer, who is now checking legal measures against me.

I don't know why he payed for the AVM hardware, but as far as I remember, it was provided by AVM as a loan. I still keep the two cards that I got in save custody. When I last inquired at Yellowtab about two years ago how I could return it, I was told that there was no need to. Still, paying for hardware is no reason to not do business, or to act crazy like this.

I understand that details like this don't look bright for Yellowtab. But I spent much time with development of BeOS software and drivers, and I really don't like to be threatened like this after all what I did. Yellowtab is acting very very treacherous. If you want to deal with them, keep their mail in mind.

I think I provided much benefit for Yellowtab during the last years, by developing software, and also by testing and reporting bugs. Some got fixed, most didn't. I was also busy getting DVB-T to work on Zeta, but I'll stop that now, and make sure that it will run on BeOS R5 and Haiku, but not on Zeta.

There is only one secure way to prevent an email from beeing published: don't write it. The complete and unaltered mail is reproduced below.

Date: Thu, 18 Aug 2005 19:06:02 +0200
Message-Id: <20050818190602.3878.3@mulsum.yellowtab.home>
From: Bernd Korz <bernd.korz@yellowtab.com>
Subject: Posting
To: marcusoverhagen@arcor.de
Cc: sonja.bauer@yellowtab.com

Hallo Marcus,

auch wenn es den Anschein hat was das Posting auf deinem Blog angeht so ist es nicht von mir. Was ich getan habe ist Dich auf dem yT.com Forum zu sperren und ich habe auch Deinen Beitrag dort gelöscht.

Ich weiss nicht was ich oder yT Dir getan hat aber ich denke wir waren immer Hilfreich. Falls Du es nicht weisst: ICH habe damals die gesamte Hardware an AVM bezahlen müssen. 1500 Euro und ich habe zu der Zeit GAR KEIN GELD gehabt. Ich habe es monatlich abbezhalt.

Warum auch immer Du so bist wie Du bist, Du wirst Deine Gründe haben. Mich interessiert es nicht wirklich. Was auch immer Du postest oder machst oder nicht machst, auch das interessiert mich nicht.

Ich will Dir nur sagen das ich mit Dir nichts mehr zu tun haben möchte, und hier spreche ich auch im Namen ALLER Entickler von yT. Du hast schon als Betatester Deinen NDA gebrochen weil Du so vergrellt bist und nun wetterst Du schon wieder, das ist sehr sehr schade denn ich denke wir haben uns wirklich bemüht Dir zu helfen.

Ich lasse gerade rechtlich prüfen in wie weit wir gegen Dich vorgehen können. Auch deshalb weil Du ja den NDA gebrochen hast. SOLLTE yT die Möglichkeit haben Dich zu verklagen so kann ich Dir versichern das ich ALLES daran setzen werde das es passieren wird. Denn Du spielst ein sehr unfaires Spiel und ich werde dem nun rechtlich entgegenwirken.

Diese email ist unter NDA und ich hoffe das Du nicht schon wieder den Fehler machst und es veröffentlichst. Ich habe diese email als CC an unseren Juristen geschickt der gerade rechtliche Schritte gegen Dich prüft.

Bernd Thorsten Korz
CVO/CEO yellowTAB GmbH

ISDN drivers for AVM B1 and Fritz cards

Today I read a few postings in the Yellowtab forum which reminded about my project to write an ISDN driver for BeOS.

For those who can read german, the complete thread is here. In a nutshell, Bernd Korz, CEO of Yellowtab, is publically saying they have been geschädigt und verarscht genug (been harmed and spoofed enough) by AVM, and that there won't be support for AVM products in Zeta for at least the next 20 years. AVM is the manufactorer of ISDN and DSL hardware.

It was in 2001, Yellowtab was just founded, Be Incorporated was still in business and busy developing BONE (BeOS new network stack), and there was no Zeta yet. BeOS R5 was still using net_server, but I was on the BONE beta program, and had access to both. Be Inc had released a beta driver for AVM B1 cards (which didn't work for me), but it was rumored that they had no permission to use the sourcecode from Marco Borm on which it was based on. At that time Marco Borm made his sourccode public, and Be Inc never ever updated their driver.

After I talked with Bernd Korz about it, I decided to try again writing a ISDN driver for BeOS. AVM provided four ISDN cards for development to Yellowtab, two active B1 cards, and two passive Fritz cards. I got one of each. My intention was to get the simple active B1 card working first. Useful documentation for the B1 card was made available, too.

The project progressed pretty fast, and after a few weeks, the card specific driver was finished. Dialing a provider's telephone number worked, and PPP frames were transmitted into both directions. I was pretty happy.

Unfortunately, net_server did crash pretty easily when dealing with PPP frames received from ISDN, and a handshake never worked. Obviously, the net_server PPP stack didn't support the synchronous PPP as used with ISDN, while it did support asynchronous PPP as used with modems.

Because of the ongoing BONE beta programm, I tried to interface the ISDN driver with the new BONE network stack. There a huge bug emerged. BONE was using 100% CPU at a very high priority when reading from the emulated serial port that the driver provided. The same problem did not happen with net_server, but it made further development pretty impossible.

To cut a long story short, it was impossible to get any support from Be Inc. that would allow to solve the problem. Development was stalled. Trying again with net_server seemed to be a bad idea, because it was meant to be replaced by BONE. Shortly after that, Be Inc went out of business, and any further development wouldn't have been useful for me. In fact, now that Yellowtab is selling Zeta, I don't even have ISDN anymore, as I'm using DSL.

When development was cancelled, I passed all sourcecode to Yellowtab, hoping they could one day continue it. Now that they are developing Zeta, and seem to have all the sourcecode for the OS, I think it should be pretty simple for them to get the AVM B1 driver that I wrote to work with Zeta's network stack, which is BONE. But the comments made by Bernd Korz in the Yellowtab forum show a completely different direction.

I think Bernd Korz is acting very childish here, and not like a business person. I can truly understand why AVM doesn't like cooperating with Yellowtab anymore. In 2001, AVM gave cards to Yellowtab, but without return. A stable BeOS AVM B1 driver never got published.
I don't know what happened recently between Yellowtab and AVM. But a company's CEO who gives negative statements like this in a public forum isn't someone you can deal with and do business.

Beeing the single developer who, closely cooperating with Yellowtab and supported by AVM, tried to help bring ISDN support to BeOS in 2001, I'm very sad about this outcome.

I really regret having been involved with Yellowtab in this case, because AVM has probably blacklisted my name by now, due to the fact that Yellowtab doesn't behave in a businesslike manner.

Good news everyone!

Last week Yellowtab sent me a updated media_server for Zeta 1.o which appears to work reliable with DVB. In the meantime, Yellowtab has made it available on their homepage, which is good for those who want to use eXposer, which was suffering from the same problem.

I also managed to get the AutoStart function working, so the DVB TV applications can use BMediaRoster::GetLiveNodes() now, and don't need some strange workarounds. It turned out that the prototype for the BMediaAddon::AutoStart() as described in the BeBook is wrong. One parameter is specified as int32, but must be an int, as done in the header file. Due to wonders of C++ name mangling, and int32 beeing defined as long on BeOS, that tiny difference is enough for the AutoStart function to get another internal name, resulting in not beeing called by the OS.

I mailed an updated DVB media-addon to Pascal today, so he can hopefully use it on his Zeta 1.0 system now for further DVB-S development.

media_server crash, and more information on live nodes

It's verified now. Zeta 1.0 media_server does crash when using the DVB media add-on. Exactly the same crash occurs when quitting eXposer. This seems to be a new bug that was introduced with release of Zeta 1.0, as it doesn't happen with the previous release, Zeta neo. It seems as if during final quality testing before Zeta 1.0 release, nobody tested eXposer. Too bad, I hope there will be an update or service pack available shortly.

I also received a reponse from Yellowtab's current media kit guy, Maurice Kalinowski. Unfortunately, it appears that the media kit doesn't make all physical input and output nodes available as live nodes, so the application has to do a little more than I expected. The complete answer is reproduced below, I assume the answers will be helpful for some of you.

Dear Mister Overhagen,
on August, 6th you have contacted me because of some issues regarding the MediaKit, especially for your work on the DVB interface. I hope the following answers will help you on your activities.

1)
Notwithstanding the use of B_FLAVOR_IS_GLOBAL in the flavor_info::flavor_flags field, media kit allows to instantiate more then one node for the flavor, and calls InstantiateNodeFor whenever BMediaRoster::InstantiateDormantNode() is called for the flavor. I also set flavor_info::possible_count to 1, but that doesn't help either, so I had to revert to a very ugly workaround.
Question: What do I have to get it working right, i.e. preventing further calls to InstantiateDormantNode() after the flavor got instantiated the first time?

Currently B_FLAVOR_IS_GLOBAL only checks wether the Node should be loaded into the Media AddOn Space or into your applications one. So it seems like BMediaRoster is instantiating additional nodes although it was not supposed to do this. I will check on this... But I am really interested in your workaround, although being ugly as you said.

2)
The flavors and nodes that are instantiated have the kind B_PHYSICAL_INPUT, I assumed that all physical input flavors would be instatiated automatically at media server startup, so that applications can find them with BMediaRoster::GetLiveNodes(). However, when having two DVB cards in the system, only the first flavor is automatically beeing instantiated, and available as live node. The BeBook says: "An active node is a node that is preloaded by the system and is always available for use, as opposed to a dormant node, which resides in an add-on and is only loaded when instantiated using InstantiateDormantNode(). "
Question: Under what conditions is a node beeing preloaded, and why is only one of my BMediaAddon flavors (nodes) beeing preloaded?

During the start of the media_server it scans the media preferences, which input is set as the default one. Afterwards this input gets instantiated and available as LiveNode. The fact, that this input is supposed to be the 'default' one, only this one got started, although there may exist multiple ones of the same kind.

3)
Question: Are all physical input / output nodes supposed to be active nodes and preloaded?

As explained in 2 only the default one set in the media preferences gets preloaded and active.

4)
If answer to 3 is "no",
Question: how should an application know which dormant nodes are already live, and which need to be instatiated? Why does the application has to care?

Until now, it just seemed reasonable that the user or the application only needs to use one physical input. This is the reason why an application should just request for the default and active inputs for audio and video. Your aspect of using multiple DVB or soundcard above is a good argument for possible changes on this.

5)
BMediaRoster has GetAudioInput() and GetVideoInput(), but these only return the interface selected in Media preferences.
Question: Whats the correct way for an application to handle multiple physical inputs, like 3 soundcards or 2 videocards?

This is the same point as in question 2 and 3. As you said GetAudioInput() and GetVideoInput() only gives you access to one media_node. This is the one selected as the default Input in the Media Preferences. If you want to use multiple inputs, you may hold the media_node_id and then use status_t BMediaRoster::GetNodeFor( media_node_id , media_node )

6)
I tried to use BMediaNode::AutoStart(), but it's never called. I'm returning true from BMediaNode::WantsAutoStart(). You can see a source snippet at addon.txt
Question: whats wrong?

I have tested something similar to your problem here in the company and it worked, so I do not really know, what might go wrong on your side. It would be great, if you may show me more of your code, so I can take a deeper look at this.
By the way you should use B_MEDIA_ADDON_FAILED in your AutoStart() function instead of B_ERROR if you want AutoStart to be called again for the next index. There is a typing error in the BeBook as it says B_ADDON_FAILED, but it is supposed to mean B_MEDIA_ADDON_FAILED.

7)
Question: When should a node use BMediaNode::AutoStart ?

A BMediaNode should only be autostarted if it is supposed to be available during the whole time a system is running. The best example for this is the Mixer as the user wants to listen to sound the whole time...

To come to an end I want to thank you again for telling us about your experiences with the MediaKit as it gives us an impression about what should be improved for developers.

Regards
Maurice Kalinowski

Recent events

This blog has now a wider audience, as it's URL got public yesterday. I hope it's interesting for you. Perhaps everyone doing any related development will benefit from this, at least I hope so.

Even Yellowtab noticed this blog, and I got the email address of a contact person for media kit related questions. They really do want to support developers, and they are also working on a more developer friendly website. Thats encouraging, and I'll keep you updated on the progress.

Furthermore, I had a few telephone calls with Pascal today, clarifying his problems. When he tries to use the DVB media add-on, his media_server does crash. I never have seen this problem before. An older version of the DVB media add-on was working well for him, but this was last tested in April and May.

I'm still using Zeta neo for DVB-T development, while Pascal is already using Zeta 1.0 for DVB-S driver development. He hasn't tested the recent add-on version with Zeta neo, and I haven't tested it with Zeta 1.0 so far. While I can't imagine whats going wrong, I'll have to run some tests using Zeta 1.0 at the weekend. However, whatever the add-on is doing, I don't think that is should be able to crash a system server process. If you are curious, here's the debugger output:

loading symbols
Buffer being recycled, but it is not in use!
_debugger:
_debugger:
+0007 e80635a7: * c3 retn
media_server:sc
frame retaddr
f8ffba80 90020890 MBufferManager::ReclaimBuffers(long const *, long, long, long) + 0000027c
f8ffbae8 90017258 _ServerApp::MReclaimOutputBuffers(BMessage *) + 000001a4
f8ffbdc0 90014e3c _ServerApp::MessageReceived(BMessage *) + 0000044c
f8ffbe40 e8170c96 BLooper::DispatchMessage(BMessage *, BHandler *) + 00000076
f8ffbe58 e8168218 BApplication::DispatchMessage(BMessage *, BHandler *) + 000007d0
f8ffc07c e81707ba BLooper::task_looper(void) + 000002a6
f8ffc31c e816617c BApplication::Run(void) + 00000068
f8ffc330 9001a7b4 main + 00000158
f8ffc4bc 900141e4 _start + 00000060
f8ffc4e8 f8ffc523 _end + 106cae73
media_server:

Bought a second DVB-T card

I got a mail from Pascal who is working on DVB-S. He seems to have some issues with the media add-on that I wrote, but only when using more than one DVB-S card. I was still using the single DVB-T card that I got from Hauppauge in November 2004, and thus wasn't able to reproduce anything.

Obvious solution was to buy another one, and after work I drove to MediaMarkt, where I picked up a new Hauppauge WinTV NOVA-T PCI card for just 79 EUR. This seems to be more expensive than ordering one for 65 EUR by mail, but you don't have to pay 15 EUR for s&h, and also it's immediately available. Good deal I think. It's the exact same card that I'm already using, model 928. Nothing new here, and is recognized out of the box, at least on my system :-)

After modifying the TV application to support multiple cards, it only found one live DVB media node, and thus only one card. Very strange. The media add-on supports an unlimited number, and has no restriction here. Zeta Media preferences shows both interfaces.

Turns out that Media preferences uses BMediaRoster::GetDormantNodes() to create the interface list, and instantiates those nodes that are not active when you select them. They are destroyed when it quits. My TV app uses BMediaRoster::GetLiveNodes(), as a the first DVB card always seems to be instantiated by the media kit. Finding a dormant node and instantiating it for the first card is not possible, it's already live.

I did assume that all physical hardware interfaces would be automatically instantiated and go live. However, the exact behaviour is not documented and the current behaviour is inconsistent.

I made a screenshot which shows two active cards, pretty nifty, but right now useless, as the audio decoder crashes pretty easily. When looking at the screenshot you may notice that you don't hear the audio, as the decoder crashed.

I also researched other ways to get all cards go live automatically, and there is BMediaAddon::AutoStart(), which never gets called, so I can't use it. Must be a bug.

Right now I'm using Zeta neo for development, and thus I tried the Yellowtab website, looking for a developer relations contact, bugreport form or other help, but didn't find any. The website only says "Developers are very important to yellowTAB. In this section you will find a collection of articles dealing with developing for the ZETA operating system." There you can find one article about the locale kit, but nothing useful for me. Also trying IRC chat with other developers, including one Yellowtab employee, didn't give me a clean solution, except putting a workaround in the (or: every) TV application, which I don't intend to do.

Multiple card support seems to be possible, but requires some ugly workaround in the TV application to instantiate those nodes that are not live.

It would still be good to find out how it's really supposed to work. If you know, please leave a comment.

Device Configuration by ACPI

I just got a bug report for the Intel AC97 audio driver that i wrote a while ago. Bummer, but let's investigate what goes wrong.

Someone bought a shiny new Asus notebook, and noticed that he gets no sound. Installing the driver debug version thats available from BeBits, he created a debugging log file, which reveals these details:

MMBAR = 0
MBBAR = 0
INTR_LN = 0xff
INTR_PN = 0x02
IRQ not assigned to pin 2
ERROR: memory mapped IO not configured

You know what this means? The sound chipset resources are not configured, memory addresses are not assigned to the BARs (base address register), and the interrupt line is also not assigned (0xff or 0 means not assigned). The driver can't do these assignments, its the responsibility of computer BIOS and operating system. The driver can only do one thing: return B_ERROR and exit.

The important thing is: This is a notebook. Notebooks need to preserve power, and thus most notebook BIOS only enable the few devices that are needed for booting, like video card and harddisk controller. Most other devices are not touched, and not even configured. They need to be configured by the operating system.

Some BIOS have a setting like "PNP OS installed" which can be set to "no" or "disabled", indicating that a dumb OS is installed. Then all devices will be configured by the BIOS. This is available on many desktop motherboard, but almost never on notebooks.

On Notebooks, exclusivlely ACPI is used. ACPI means Advanced Configuration and Power Interface, and is available since spring 2001 in almost every desktop computer and notebook system. It's a specification that describes how the operating system can query which hardware is installed, and allows to configure them and assign resources. Some older systems can be configured by chipset specific PCI functions, but ACPI is better and doesn't depend on proprietary vendor specifications.

Unfortunately, BeOS and also Zeta is based on a design that is slightly older than 2001, and has neither PCI chipset specific, nor ACPI based device configuration implemented. If the motherboard doesn't have a "PNP OS installed" = "no" option, chances are that many devices like sound chipset, USB controller, network or TV cards won't work.

This is bad, very bad. Not only for the user, but also for us "your f***ing driver doesn't work here" driver writers.

DVB driver development, some thoughts

This is no introduction about how to do driver development. Just a short intro showing that you usually don't write one in a single day, and about the progress of the DVB driver.

On windows, we can use Tortoise SVN to manage SVN sourcecode repositories. Especially the history view is convenient, it also allows to select arbitrary versions, to check them out or compare them. Using a good revision control system is always a helpful idea. Whatever you did to your working copy, you can revert it to the last version with a simple command.

The DVB-T driver is still not finished, for example automatic tuning is still missing, but so far it's fairly complete. I made a image of the history of this driver available for those who are curious.

As you can see, I worked on it on 26 days during the last 8 month. A have no accourate number about the hours spend for development, but I'm fairly sure that it was better than spending them watching TV, or surfing in the internet. What are you doing right now?

Assuming a average of 5 hours each day, this means 130 hours kernel driver development. But I'm sure I spend much more time on it, I just didn't always do a SVN checkin. 180 to 200 hours, including the needed research, seems proper to me. This is still not including the time spend on the userspace things, like the demultiplexing and decoding media add-on, or the TV application.

The driver is still not published. I'm not sure if I'll ever publish it. The majority of the BeOS community doesn't want to pay for drivers. But cconsidering all the work spend on it, giving it away for free seems to be a stupid idea.