Multiproto API/Driver Update
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Greetings.
First I would like to thank everyone for their patience. Multiproto has been under development for some time and I know many of you have been anxious for its arrival. I would also like to thank all the people who've helped code and test the new api. Last but not least, a thanks to the app developers who've supported multiproto, and whose continued support is very much appreciated.
As you might already know, I've been out-of-town for the last few months and haven't been able to progress multiproto further. I've now returned and am glad to announce I've been putting the finishing touches on the multiproto api, along with many fixes/updates to supported drivers. Multiproto has reached a state where it is ready to be adopted into the kernel and already has a pull request to do so.
Here are some important pieces of information for you to know:
current supported modulations with supported hardware:
DVB-S, DVB-S2, DVB-T, DVB-C, DVB-H
How big is multiproto?
It's not. It doesn't exceed the size of the legacy api and is infact smaller when used in non-legacy mode.
Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
Intentionally, no! Experience with the old api development has proven that making blind assumptions about delivery systems is a bad idea. It's better to add in support for these when the hardware actually arrives and can be properly tested. There is enough reserved space in the api to support future modulations.
current supported chipsets/devices:
STB0899 based cards (AD SP400/VP-1041, TT S2 3200, KNC1 DVB-S2 etc.)
drivers currently in development:
STB0900/STB0903 based (eg. SAA716x based cards: AD SE-200/VP-1028, etc.)
To clear up some misinformation and misconceptions:
Is multiproto backwards compatible with previously built binaries? YES! You don't need to do anything to make it backward compatible.
Does multiproto have support for drivers found in v4l?
YES! Multiproto includes the v4l tree as well. However, the software you use must support the multiproto api in order to use them. Fortunately many already do but in the event support for the api must be added, it can usually be done with minor changes.
Are new modulations possible?
YES! Multiproto has been designed so that adding new future modulations may be done with minimal effort. This will help speed up the driver development process and allow us to use this api for some time to come.
If you would like to use any of these drivers now, you may pull the tree from http://jusst.de/hg/multiproto. Drivers may be configured with 'make menuconfig' the same as you've done with v4l.
Feedback, bug reports, etc. are welcomed and encouraged! Please feel free to
contact me via email at: [email protected]
If you have an unsupported device, please let me know!
Best Regards,
Manu
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Hi, Manu
is it possible to patch scan2 for dvb-s2 support ?
Goga
Quoted 59 lines
Greetings.
First I would like to thank everyone for their patience. Multiproto has been under development for some time and I know many of you have been anxious for its arrival. I would also like to thank all the people who've helped code and test the new api. Last but not least, a thanks to the app developers who've supported multiproto, and whose continued support is very much appreciated.
As you might already know, I've been out-of-town for the last few months and haven't been able to progress multiproto further. I've now returned and am glad to announce I've been putting the finishing touches on the multiproto api, along with many fixes/updates to supported drivers. Multiproto has reached a state where it is ready to be adopted into the kernel and already has a pull request to do so.
Here are some important pieces of information for you to know:
current supported modulations with supported hardware:
DVB-S, DVB-S2, DVB-T, DVB-C, DVB-HHow big is multiproto?
It's not. It doesn't exceed the size of the legacy api and is infact smaller when used in non-legacy mode.Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
Intentionally, no! Experience with the old api development has proven that making blind assumptions about delivery systems is a bad idea. It's better to add in support for these when the hardware actually arrives and can be properly tested. There is enough reserved space in the api to support future modulations.current supported chipsets/devices:
STB0899 based cards (AD SP400/VP-1041, TT S2 3200, KNC1 DVB-S2 etc.)drivers currently in development:
STB0900/STB0903 based (eg. SAA716x based cards: AD SE-200/VP-1028, etc.)To clear up some misinformation and misconceptions:
Is multiproto backwards compatible with previously built binaries? YES! You don't need to do anything to make it backward compatible.
Does multiproto have support for drivers found in v4l?
YES! Multiproto includes the v4l tree as well. However, the software you use must support the multiproto api in order to use them. Fortunately many already do but in the event support for the api must be added, it can usually be done with minor changes.Are new modulations possible?
YES! Multiproto has been designed so that adding new future modulations may be done with minimal effort. This will help speed up the driver development process and allow us to use this api for some time to come.If you would like to use any of these drivers now, you may pull the tree from http://jusst.de/hg/multiproto. Drivers may be configured with 'make menuconfig' the same as you've done with v4l.
Quoted 8 lines
Feedback, bug reports, etc. are welcomed and encouraged! Please feel free to
contact me via email at: [email protected]If you have an unsupported device, please let me know!
Best Regards,
Manu
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Hi Goga,
Quoted 3 lines · Goga777 wrote:
Hi, Manu
is it possible to patch scan2 for dvb-s2 support ?
Will do so.
Regards,
Manu
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 6 lines · Manu Abraham
Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
Intentionally, no! Experience with the old api development has proven that making blind assumptions about delivery systems is a bad idea. It's better to add in support for these when the hardware actually arrives and can be properly tested.
Full ACK on this one. Once an API is merged into the mailine kernel we're stuck with it, no matter how ugly and broken it might be. -> NEVER merge untested APIs
Quoted 5 lines
If you would like to use any of these drivers now, you may pull the tree from http://jusst.de/hg/multiproto. Drivers may be configured with 'make menuconfig' the same as you've done with v4l.
Feedback, bug reports, etc. are welcomed and encouraged!
I only want to add a bit of historical perspective so people are aware of the reasons why Steve came up with his alternative API proposal, and why a number of developers seem to support it.
First let's look at the timestamps:
http://jusst.de/hg/multiproto/log/2a911b8f9910/linux/include/linux/dvb/frontend.h
http://jusst.de/hg/multiproto_api_merge/log/4c62efb08ea6/linux/include/linux/dvb/frontend.h
Then at some discussion from nearly one year ago:
http://article.gmane.org/gmane.linux.drivers.dvb/36643
Johannes
Signature · 7 lines
"Folks, As vou can see for yourself. The way this clock over here is behaving, TIME IS OF AFFLICTION! Now this might be cause for alarm Among a portion of you, as,
Quoted 1 line
From a certain experience,
I TEND TO PROCLAIM:
'THE EONS ARE CLOSING'!" -- Frank Zappa
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Hi,
Quoted 8 lines · Johannes Stezenbach
Quoted 6 lines · Manu Abraham
Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
Intentionally, no! Experience with the old api development has proven that making blind assumptions about delivery systems is a bad idea. It's better to add in support for these when the hardware actually arrives and can be properly tested.
I have Empia ISDB-T and DMB-T/H hardware and the corresponding signal generator for it here,
it's right on my roadmap and work can be started within a few days.
Quoted 3 lines
Full ACK on this one. Once an API is merged into the mailine kernel we're stuck with it, no matter how ugly and broken it might be. -> NEVER merge untested APIs
should be the rule but there's always an exception for it too . o ( thinking about KVM )
Quoted 11 lines
Quoted 6 lines
If you would like to use any of these drivers now, you may pull the tree from http://jusst.de/hg/multiproto. Drivers may be configured with 'make menuconfig' the same as you've done with v4l.
Feedback, bug reports, etc. are welcomed and encouraged!
I only want to add a bit of historical perspective so people are aware of the reasons why Steve came up with his alternative API proposal, and why a number of developers seem to support it.
Quoted 7 lines
First let's look at the timestamps:
http://jusst.de/hg/multiproto/log/2a911b8f9910/linux/include/linux/dvb/frontend.h
http://jusst.de/hg/multiproto_api_merge/log/4c62efb08ea6/linux/include/linux/dvb/frontend.hThen at some discussion from nearly one year ago:
http://article.gmane.org/gmane.linux.drivers.dvb/36643
by experience I'm sure most people won't read up the history here...
Markus
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 9 lines · Markus Rechberger
Hi,
Quoted 6 lines · Johannes Stezenbach
Quoted 5 lines · Manu Abraham
Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
Intentionally, no! Experience with the old api development has proven that making blind assumptions about delivery systems is a bad idea. It's better to add in support for these when the hardware actually arrives and can be properly tested.
We have ISDB-T running under linux in the lab, we have a pretty good idea about what we need to generalize for an API, but you can't make a standard out of one demod.
All API's developers should be cautious here.
Quoted 4 lines
I have Empia ISDB-T and DMB-T/H hardware and the corresponding signal generator for it here,
it's right on my roadmap and work can be started within a few days.
A big difference between can and will, the em28xx fiasco tells us this.
I hope this next question isn't seen as a flame, because I ask this as a genuine question. Are you committing to adding ISDB-T and DMB-T/H support to master at linuxtv.org? Or would this be something you'd plan to keep at you own site, like your other code?
Quoted 4 lines
Quoted 4 lines
Full ACK on this one. Once an API is merged into the mailine kernel we're stuck with it, no matter how ugly and broken it might be. -> NEVER merge untested APIs
Indeed.
Quoted 12 lines
should be the rule but there's always an exception for it too . o ( thinking about KVM )
Quoted 8 lines
Quoted 5 lines
If you would like to use any of these drivers now, you may pull the tree from http://jusst.de/hg/multiproto. Drivers may be configured with 'make menuconfig' the same as you've done with v4l.
Feedback, bug reports, etc. are welcomed and encouraged!
I only want to add a bit of historical perspective so people are aware of the reasons why Steve came up with his alternative API proposal, and why a number of developers seem to support it.
/me nods
Quoted 7 lines
Quoted 7 lines
First let's look at the timestamps:
http://jusst.de/hg/multiproto/log/2a911b8f9910/linux/include/linux/dvb/frontend.h
http://jusst.de/hg/multiproto_api_merge/log/4c62efb08ea6/linux/include/linux/dvb/frontend.hThen at some discussion from nearly one year ago:
http://article.gmane.org/gmane.linux.drivers.dvb/36643
This is worth reading.
Quoted 3 lines
Quoted 1 line
by experience I'm sure most people won't read up the history here...
Also agreed, a lot of people have lost sight of the history - which is the entire reason that the S2API alternative exists.
Manu,
The S2API tree is available on linuxtv.org with HVR4000 support, spanning 3 or 4 patches.
I have a TT-3200, do you have a complete tree with all of your pull req'd patches available on linuxtv.org for testing, including your demodulation and tuning drivers? Do you have a complete solution that I can evaluate for pro's and cons?
Thanks,
Steve
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 2 lines · Steven Toth
A big difference between can and will, the em28xx fiasco tells us this.
just wondering if your tree will go any way towards resolving that little problem?
--
simo
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 5 lines · Simon Kenyon
Quoted 2 lines · Steven Toth
A big difference between can and will, the em28xx fiasco tells us this.
just wondering if your tree will go any way towards resolving that little problem?
I don't see any fiasco nor problem here, it's more comfortable to have the em28xx in an extra
tree and do ongoing development with it. People who followed the development during the last
few years know that newer things got added and newer chips are supported by it, it will continue
to evolve anyway.
The driverwork is currently around 30% of it, patching applications and providing full support from
the driver till the endapplications is what everything's focussing on mcentral.de not just driver only
development.
We do dedicated application support for several customers too (analog tv, radio, dvb integration in their
business applications).
There are many new products coming up, adding support for them is on the roadmap.
Markus
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 25 lines · Markus Rechberger
Quoted 8 lines · Simon Kenyon
Quoted 3 lines · Steven Toth
A big difference between can and will, the em28xx fiasco tells us this.
just wondering if your tree will go any way towards resolving that little problem?
I don't see any fiasco nor problem here, it's more comfortable to have the em28xx in an extra
tree and do ongoing development with it. People who followed the development during the last
few years know that newer things got added and newer chips are supported by it, it will continue
to evolve anyway.The driverwork is currently around 30% of it, patching applications and providing full support from
the driver till the endapplications is what everything's focussing on mcentral.de not just driver only
development.
Quoted 9 lines
We do dedicated application support for several customers too (analog tv, radio, dvb integration in their
business applications).
There are many new products coming up, adding support for them is on the roadmap.Markus
i have had the device for a while now
i originally got it because the wiki showed that support was being worked on then that all changed and you moved your stuff elsewhere
i really don't understand your rationale. i really don't. i'm not trying to start a flame war, but your arguments for having your own tree and doing stuff user side makes no sense
let my try to explain:
you say:
Quoted 1 line
it is more comfortable to have the em28xx in an extra tree
it may very well be comfortable for you. but it is impossible for me i have lots of different devices. i can choose between using your tree and having support for one of them.
or i change choose the linuxtv.org tree and have supoort for all the other. how is that "more comfortable"?
i really don't understand that argument
you then say:
Quoted 1 line
newer things get added and newer chips are supported by it
how does that help me? it doesn't, as far as i can see
next you say:
Quoted 1 line
the driverwork is currently around 30% of it, patching applications
and providing full support from the driver till the...
apart from the little speedbump that is multiproto vs. s2api most apps don't need "supporting". they are already supported by their respective communities.
Quoted 1 line
we do dedicated application support for several customers...
now i think we get to the heart of the matter.
you have built up a nice little business providing support for the various devices. you have customers who (in my humble opinion misguidedly) think that by having support in your tree that they can proudly boast "linux supported". all i can say is well done. congratulations on building a sucessful business.
but please do not mistake that for providing linux support for the em28xx devices in linux. what you are providing and "linux support of the em28xx class of devices" are not one and the same thing. for better or worse, linux support means that at some point (and it may well be one year from now) it will be in the kernel.
have you not seen all the software that has come and gone because linus will not put it in the tree. right now the only route to doing that is to get it in the linuxtv.org tree. from there it stands some chance of making it into the kernel. i seriously doubt that any other approach has any chance of success.
this may not be of concern or interest to you. well so be it. but it is important to me.
regards and best of luck
--
simon
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 96 lines · Simon Kenyon
Quoted 29 lines · Markus Rechberger
Quoted 11 lines · Simon Kenyon
Quoted 4 lines · Steven Toth
A big difference between can and will, the em28xx fiasco tells us this.
just wondering if your tree will go any way towards resolving that little problem?
I don't see any fiasco nor problem here, it's more comfortable to have the em28xx in an extra
tree and do ongoing development with it. People who followed the development during the last
few years know that newer things got added and newer chips are supported by it, it will continue
to evolve anyway.The driverwork is currently around 30% of it, patching applications and providing full support from
the driver till the endapplications is what everything's focussing on mcentral.de not just driver only
development.Quoted 9 lines
We do dedicated application support for several customers too (analog tv, radio, dvb integration in their
business applications).
There are many new products coming up, adding support for them is on the roadmap.Markus
i have had the device for a while now
i originally got it because the wiki showed that support was being worked on then that all changed and you moved your stuff elsewherei really don't understand your rationale. i really don't.
i'm not trying to start a flame war, but your arguments for having your own tree and doing stuff user side makes no senselet my try to explain:
you say:
Quoted 1 line
it is more comfortable to have the em28xx in an extra tree
it may very well be comfortable for you. but it is impossible for me i have lots of different devices. i can choose between using your tree and having support for one of them.
or i change choose the linuxtv.org tree and have supoort for all the other. how is that "more comfortable"?
i really don't understand that argumentyou then say:
Quoted 1 line
newer things get added and newer chips are supported by it
how does that help me? it doesn't, as far as i can see
next you say:
Quoted 2 lines
the driverwork is currently around 30% of it, patching applications and providing full support from the driver till the...
apart from the little speedbump that is multiproto vs. s2api most apps don't need "supporting". they are already supported by their respective communities.
Quoted 1 line
we do dedicated application support for several customers...
now i think we get to the heart of the matter.
you have built up a nice little business providing support for the various devices. you have customers who (in my humble opinion misguidedly) think that by having support in your tree that they can proudly boast "linux supported". all i can say is well done. congratulations on building a sucessful business.but please do not mistake that for providing linux support for the em28xx devices in linux. what you are providing and "linux support of the em28xx class of devices" are not one and the same thing. for better or worse, linux support means that at some point (and it may well be one year from now) it will be in the kernel.
have you not seen all the software that has come and gone because linus will not put it in the tree. right now the only route to doing that is to get it in the linuxtv.org tree. from there it stands some chance of making it into the kernel. i seriously doubt that any other approach has any chance of success.
Quoted 3 lines
this may not be of concern or interest to you. well so be it. but it is important to me.
the code on mcentral.de didn't write itself, it was mostly written from our side.
If you're going to pay my monthly insurance for working together with linuxtv.org (something has to
compensate the slowdown of the development due those endless wanted discussions) I'll be glad to
go that way.
Application development and driver development is right now at an acceptable speed, noone bothers
about fixed drivers there which improve the signal strength etc.
The code is already used with BSD [1] now and will be used by our OSX driver in near future.
Markus
[1] http://netbsd-soc.sourceforge.net/projects/dvb/
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Hi,
Quoted 5 lines · Markus Rechberger
If you're going to pay my monthly insurance for working together with linuxtv.org (something has to
compensate the slowdown of the development due those endless wanted discussions) I'll be glad to
go that way.
Your choosen way doesn't compensate the non-ending diskusions too. Maybe you should start to show other developers how things can go on without slowing down development and
building drivers out of official kernel tree?
I read most of the mails on this list and
the current situation is really annoying.
1. We have multiproto
2. We have s2-API
3. We have your drivers at mcentral.de
Please go on alltogether and stop working against each other. Have a nice Day
Halim
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 16 lines · Halim Sahin
Hi,
Quoted 5 lines · Markus Rechberger
If you're going to pay my monthly insurance for working together with linuxtv.org (something has to
compensate the slowdown of the development due those endless wanted discussions) I'll be glad to
go that way.Your choosen way doesn't compensate the non-ending diskusions too. Maybe you should start to show other developers how things can go on without slowing down development and
building drivers out of official kernel tree?I read most of the mails on this list and
the current situation is really annoying.
Quoted 6 lines
1. We have multiproto
2. We have s2-API
3. We have your drivers at mcentral.dePlease go on alltogether and stop working against each other. Have a nice Day
S2API is available on linuxtv.org, along with all of my other trees. I don't get paid by Hauppauge to work on Linux.... I chose to work from linuxtv.org because I love Linux and I believe that's where the heart of the community belongs.
Fragmenting tree's to mcentral.de or Manu's repo (just.de?) shows that those developers don't want to contribute to the community at linuxtv.org.
S2API is actively maintained at linuxtv.org, where the community owns the code.
- Steve
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 2 lines · Steven Toth
Fragmenting tree's to mcentral.de or Manu's repo (just.de?) shows that those developers don't want to contribute to the community at linuxtv.org.
Since it is another round of spreading lies and false accusations, i will respond.
http://thread.gmane.org/gmane.linux.kernel/729892
http://thread.gmane.org/gmane.linux.kernel/729969
also at
http://www.kernel.org/pub/linux/kernel/people/manu/dvb_patches/
Normally anyone sane would think that the linux-kernel @kernel.org is just a superset of any smaller Linux-* communities.
Maybe you just need to find a newer topic to spread Fear, Uncertainty and Doubt (FUD).
Regards,
Manu
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
-------- Original-Nachricht --------
Quoted 22 lines
Datum: Mon, 08 Sep 2008 21:54:46 +0400
Von: Manu Abraham <[email protected]>
An: [email protected]
Betreff: Re: [linux-dvb] Multiproto API/Driver UpdateQuoted 2 lines · Steven Toth
Fragmenting tree's to mcentral.de or Manu's repo (just.de?) shows that those developers don't want to contribute to the community at
linuxtv.org.
Since it is another round of spreading lies and false accusations, i will respond.
http://thread.gmane.org/gmane.linux.kernel/729892
http://thread.gmane.org/gmane.linux.kernel/729969
also at
http://www.kernel.org/pub/linux/kernel/people/manu/dvb_patches/
Quoted 8 lines
Normally anyone sane would think that the linux-kernel @kernel.org is just a superset of any smaller Linux-* communities.
Maybe you just need to find a newer topic to spread Fear, Uncertainty and Doubt (FUD).
Regards,
Manu
Where's the beef? The drivers are missing.
http://linuxtv.org/pipermail/linux-dvb/2008-September/028445.html
Signature · 9 lines
Release early, release often. Psssst! Schon das coole Video vom GMX MultiMessenger gesehen? Der Eine für Alle: http://www.gmx.net/de/go/messenger03 _______________________________________________ linux-dvb mailing list [email protected] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 27 lines · Hans Werner
-------- Original-Nachricht --------
Quoted 25 lines
Datum: Mon, 08 Sep 2008 21:54:46 +0400
Von: Manu Abraham <[email protected]>
An: [email protected]
Betreff: Re: [linux-dvb] Multiproto API/Driver UpdateQuoted 2 lines · Steven Toth
Fragmenting tree's to mcentral.de or Manu's repo (just.de?) shows that those developers don't want to contribute to the community at
linuxtv.org.
Since it is another round of spreading lies and false accusations, i will respond.
http://thread.gmane.org/gmane.linux.kernel/729892
http://thread.gmane.org/gmane.linux.kernel/729969
also at
http://www.kernel.org/pub/linux/kernel/people/manu/dvb_patches/
Normally anyone sane would think that the linux-kernel @kernel.org is just a superset of any smaller Linux-* communities.
Quoted 9 lines
Quoted 5 lines
Maybe you just need to find a newer topic to spread Fear, Uncertainty and Doubt (FUD).
Regards,
ManuWhere's the beef? The drivers are missing.
http://linuxtv.org/pipermail/linux-dvb/2008-September/028445.html
The drivers will come afterwards, first the split out framework afterwards the rest.
(just as far as I understood).
I fully agree with Manu though.
Markus
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 3 lines · Hans Werner
Where's the beef? The drivers are missing.
http://linuxtv.org/pipermail/linux-dvb/2008-September/028445.html
If you have read the post or the links what i sent or what i wrote maybe you would have understood.
Also, i don't know whether you are the same Hans Werner as in here:
http://article.gmane.org/gmane.linux.drivers.dvb/44017
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 90 lines · Simon Kenyon
Quoted 24 lines · Markus Rechberger
Quoted 8 lines · Simon Kenyon
Quoted 3 lines · Steven Toth
A big difference between can and will, the em28xx fiasco tells us this.
just wondering if your tree will go any way towards resolving that little problem?
I don't see any fiasco nor problem here, it's more comfortable to have the em28xx in an extra
tree and do ongoing development with it. People who followed the development during the last
few years know that newer things got added and newer chips are supported by it, it will continue
to evolve anyway.The driverwork is currently around 30% of it, patching applications and providing full support from
the driver till the endapplications is what everything's focussing on mcentral.de not just driver only
development.Quoted 9 lines
We do dedicated application support for several customers too (analog tv, radio, dvb integration in their
business applications).
There are many new products coming up, adding support for them is on the roadmap.Markus
i have had the device for a while now
i originally got it because the wiki showed that support was being worked on then that all changed and you moved your stuff elsewherei really don't understand your rationale. i really don't. i'm not trying to start a flame war, but your arguments for having your own tree and doing stuff user side makes no sense
let my try to explain:
you say:
Quoted 1 line
it is more comfortable to have the em28xx in an extra tree
it may very well be comfortable for you. but it is impossible for me i have lots of different devices. i can choose between using your tree and having support for one of them.
or i change choose the linuxtv.org tree and have supoort for all the other. how is that "more comfortable"?
i really don't understand that argumentyou then say:
Quoted 1 line
newer things get added and newer chips are supported by it
how does that help me? it doesn't, as far as i can see
next you say:
Quoted 1 line
the driverwork is currently around 30% of it, patching applications
and providing full support from the driver till the...
apart from the little speedbump that is multiproto vs. s2api most apps don't need "supporting". they are already supported by their respective communities.
Quoted 1 line
we do dedicated application support for several customers...
now i think we get to the heart of the matter.
you have built up a nice little business providing support for the various devices. you have customers who (in my humble opinion misguidedly) think that by having support in your tree that they can proudly boast "linux supported". all i can say is well done. congratulations on building a sucessful business.but please do not mistake that for providing linux support for the em28xx devices in linux. what you are providing and "linux support of the em28xx class of devices" are not one and the same thing. for better or worse, linux support means that at some point (and it may well be one year from now) it will be in the kernel.
have you not seen all the software that has come and gone because linus will not put it in the tree. right now the only route to doing that is to get it in the linuxtv.org tree. from there it stands some chance of making it into the kernel. i seriously doubt that any other approach has any chance of success.
Quoted 2 lines
this may not be of concern or interest to you. well so be it. but it is important to me.
Good comments Simon, and I largely agree with you.
I've tried to help mediate on issues like this in the past, trying to get the em28xx tree back to linuxtv.org and in the master repo. But, people are people and the major players fundamentally disagree about major issues. We can't find a way to resolve this - and I don't think it will ever be resolved.
Pity, because Hauppauge sold a lot of em28xx based products, as did many other companies.
- Steve
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 5 lines · Simon Kenyon
Quoted 2 lines · Steven Toth
A big difference between can and will, the em28xx fiasco tells us this.
just wondering if your tree will go any way towards resolving that little problem?
I have enough in the API now to tune some experimental ISDB-T products we have in the lab. That code is already in the the tune.c for anyone to view.
Like everything, it will evolve over time but the code is available now for you to view in tune.c
- Steve
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 10 lines · Markus Rechberger
Hi,
Quoted 6 lines · Johannes Stezenbach
Quoted 5 lines · Manu Abraham
Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
Intentionally, no! Experience with the old api development has proven that making blind assumptions about delivery systems is a bad idea. It's better to add in support for these when the hardware actually arrives and can be properly tested.
Quoted 3 lines
I have Empia ISDB-T and DMB-T/H hardware and the corresponding signal generator for it here,
it's right on my roadmap and work can be started within a few days.
With all due respect, their is a big difference between can and will.
Are you committing to adding ISDB-T and DMB-T/H support, and having that code live at linuxtv.org?
Or, are these patches something that you'd want to keep in your out-of-kernel trees at mcentral.de, like your other works? (This isn't am opportunity to flame, it's a genuine question - I'm interested in your future direction plans).
Quoted 7 lines
Quoted 4 lines
Full ACK on this one. Once an API is merged into the mailine kernel we're stuck with it, no matter how ugly and broken it might be. -> NEVER merge untested APIs
should be the rule but there's always an exception for it too . o ( thinking about KVM )
We don't add API's that can't be tested, that's just a basic rule.
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
If you would like to use any of these drivers now, you may pull the tree from http://jusst.de/hg/multiproto. Drivers may be configured with 'make menuconfig' the same as you've done with v4l.
Feedback, bug reports, etc. are welcomed and encouraged!
I only want to add a bit of historical perspective so people are aware of the reasons why Steve came up with his alternative API proposal, and why a number of developers seem to support it.
Yes.
Quoted 7 lines
Quoted 7 lines
First let's look at the timestamps:
http://jusst.de/hg/multiproto/log/2a911b8f9910/linux/include/linux/dvb/frontend.h
http://jusst.de/hg/multiproto_api_merge/log/4c62efb08ea6/linux/include/linux/dvb/frontend.hThen at some discussion from nearly one year ago:
http://article.gmane.org/gmane.linux.drivers.dvb/36643
This is a great one page email, worth reading everyone.
Quoted 3 lines
Quoted 1 line
by experience I'm sure most people won't read up the history here...
Maybe.
Manu,
The S2API tree is available on linuxtv.org for people to download and experiment with. It has HVR4000 DVB-S2 support, QAM, ATSC, DVB-S and DVB-T. These are known to work with the exercising tool. We are testing ISDB-T over the next few days.... It's preliminary.
I need to do some comparison for plumbers.
Why aren't you issuing a pull request that includes the 3200 drivers?
- Steve
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Am Donnerstag, den 04.09.2008, 22:47 +0200 schrieb Johannes Stezenbach:
Quoted 31 lines · Manu Abraham
Quoted 6 lines
Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
Intentionally, no! Experience with the old api development has proven that making blind assumptions about delivery systems is a bad idea. It's better to add in support for these when the hardware actually arrives and can be properly tested.Full ACK on this one. Once an API is merged into the mailine kernel we're stuck with it, no matter how ugly and broken it might be. -> NEVER merge untested APIs
Quoted 5 lines
If you would like to use any of these drivers now, you may pull the tree from http://jusst.de/hg/multiproto. Drivers may be configured with 'make menuconfig' the same as you've done with v4l.
Feedback, bug reports, etc. are welcomed and encouraged!
I only want to add a bit of historical perspective so people are aware of the reasons why Steve came up with his alternative API proposal, and why a number of developers seem to support it.
First let's look at the timestamps:
http://jusst.de/hg/multiproto/log/2a911b8f9910/linux/include/linux/dvb/frontend.h
http://jusst.de/hg/multiproto_api_merge/log/4c62efb08ea6/linux/include/linux/dvb/frontend.hThen at some discussion from nearly one year ago:
http://article.gmane.org/gmane.linux.drivers.dvb/36643Johannes
Signature · 7 lines
"Folks, As vou can see for yourself. The way this clock over here is behaving, TIME IS OF AFFLICTION! Now this might be cause for alarm Among a portion of you, as,
Quoted 1 line
From a certain experience,
I TEND TO PROCLAIM:
'THE EONS ARE CLOSING'!" -- Frank Zappa
OK, maybe more quoting does help a little.
"Im Falschen kann es nichts Richtiges geben."
Theodor W. Adorno
"Da steh ich nun ich armer Tor und bin so klug als je zuvor."
Johann Wolfgang von Goethe
"Wo viel Licht ist, ist auch viel Schatten."
As said previously, the "best" interpreter ever was Ronald Reagan on his Berlin speech ...
Again the same author.
In general I prefer Zappa too, it's more like driving beans to Utah or that one with the fried chickens :)
Cheers,
Hermann
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Seeing how hot API discussion got lately I think it's time to write on the subject.
Some time ago a discussion went on multiple TS support in DVB-S2, see:
http://article.gmane.org/gmane.linux.drivers.dvb/37299
I know that is a typical broadcaster application that a "normal" user won't benefit so much, but I'd love to see it implemented as I think v4l-dvb will gain some professional adoption.
From a purely technical point of view how hard will be to extend
multiproto to support such feature? And is S2API ready for the same?
I'd like also to see support for non-tuning devices like ASI input cards, is it planned?
thanks
Francesco
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 6 lines · Francesco Schiavarelli
Seeing how hot API discussion got lately I think it's time to write on the subject.
Some time ago a discussion went on multiple TS support in DVB-S2, see:
Yes, i do remember.
Quoted 6 lines
I know that is a typical broadcaster application that a "normal" user won't benefit so much, but I'd love to see it implemented as I think v4l-dvb will gain some professional adoption.
From a purely technical point of view how hard will be to extend multiproto to support such feature?
The data structure is quite simple with regards to S2. We've had some lab tests only on this feature and not wide spread tests and results. If someone can provide access to such streams in practical life it would be quite easy to add it.
Quoted 2 lines
And is S2API ready for the same?
No idea. i guess not.
Quoted 2 lines
I'd like also to see support for non-tuning devices like ASI input cards, is it planned?
We've had a discussion on ASI input. Also i do have an ASI patch on my machine somewhere here. It can be added in to multiproto quite easily.
Regards,
Manu
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Ciao,
Quoted 2 lines · Francesco Schiavarelli
Seeing how hot API discussion got lately I think it's time to write on the subject.
I'm going to avoid giving an opinion, because I don't have one to give as an outsider, other than whatever works, is good...
What I wonder, is two things.
Does DiSEqC 1.1 fit into the existing API, and is it more of a question of hardware support (generally I've noticed 1.0 and 1.2 listed), and applications being able to handle the additional switching (I've found an app limit of 4 positions)?
I don't know enough about the internals of DiSEqC to have any idea what I'm talking about; I've got a 1.1 switch on order, and I have a 1.1-able 8/1+16/1 receiver, where those appear to be incompatible with my existing 4/1 switch.
Second, how do non-DVB-like technologies like DAB (Eureka-147) fit into the scope of either multiproto or S2API -- or must they remain outside of v4l-dvb?
The Wiki sez, ``some developers already have hardware using standards unsupported by multiproto, such as ISDB-T and DMB-T/H.'' And some of us non-developers have such hardware and want to try it with non-Windows for readily-receiveable DAB.
Or is DAB/T-DMB too different from DVB and related technologies, that a separate development path needs to be taken outside linux-dvb, but probably within V4L?
thanks,
barry bouwsma
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 2 lines · barry bouwsma
Ciao,
[..]
Quoted 7 lines
What I wonder, is two things.
Does DiSEqC 1.1 fit into the existing API, and is it more of a question of hardware support (generally I've noticed 1.0 and 1.2 listed), and applications being able to handle the additional switching (I've found an app limit of 4 positions)?
Cascading is not supported by the dvb-apps, i must say. It's more of a support from the application side.
As far as multiproto goes, the driver used alongwith it supports DiSEqC 2.0
Quoted 9 lines
I don't know enough about the internals of DiSEqC to have any idea what I'm talking about; I've got a 1.1 switch on order, and I have a 1.1-able 8/1+16/1 receiver, where those appear to be incompatible with my existing 4/1 switch.
Second, how do non-DVB-like technologies like DAB (Eureka-147) fit into the scope of either multiproto or S2API -- or must they remain outside of v4l-dvb?
There is already a kernel module called dabusb for ages.
Quoted 4 lines
The Wiki sez, ``some developers already have hardware using standards unsupported by multiproto, such as ISDB-T and DMB-T/H.'' And some of us non-developers have such hardware and want to try it with non-Windows for readily-receiveable DAB.
With some simple definitions ? What applications are used ? With regards to ISDB-T, there was an idea to integrate the ARIB extension used in the DVB V4 API, but then it was proven that there wasn't much use for the same due to:
* lack of available hardware (only some mobile devices using 1 seg or likewise were available) Of course, there was the demodulator from Toshiba TCxxxx, the DVB V4 API which it was based on.
* most of the stuff's completely scrambled and the scrambling schemes are not open like DVB stuff.
But still, if there's need to add support for the same into the multiproto tree, it is quite trivial.
Quoted 3 lines
Or is DAB/T-DMB too different from DVB and related technologies, that a separate development path needs to be taken outside linux-dvb, but probably within V4L?
DMB resembles quite a bit of DAB. Well, the tables for DMB-T/H is quite different from standard DVB tables, but still you can use multiproto to handle DMB-T/H, it's quite trivial.
Regards,
Manu
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Is there any change in the cultiproto disecq code?
For example
MythTV won't tune to channels on disecq port 2 or higher. (Disecq port 1 always works)
However, Kaffeine works. I'm able to watch every BBC channel on Astra 28,2 (which is on my second port)
This made me think it's MythTV.
But a friend of mine now said an older, regular DVB-S card DOES work with disecq.
I must point out that I'm not using the latest multiproto drivers, the one with the old_api support (so that I don't have to patch mythtv)
/Met vriendelijke groeten,/
*Jelle De Loecker*
Kipdola Studios - Tomberg
Manu Abraham schreef:
Quoted 71 lines
Quoted 3 lines · barry bouwsma
Ciao,
[..]
Quoted 7 lines
What I wonder, is two things.
Does DiSEqC 1.1 fit into the existing API, and is it more of a question of hardware support (generally I've noticed 1.0 and 1.2 listed), and applications being able to handle the additional switching (I've found an app limit of 4 positions)?
Cascading is not supported by the dvb-apps, i must say. It's more of a support from the application side.
As far as multiproto goes, the driver used alongwith it supports DiSEqC 2.0
Quoted 10 lines
I don't know enough about the internals of DiSEqC to have any idea what I'm talking about; I've got a 1.1 switch on order, and I have a 1.1-able 8/1+16/1 receiver, where those appear to be incompatible with my existing 4/1 switch.
Second, how do non-DVB-like technologies like DAB (Eureka-147) fit into the scope of either multiproto or S2API -- or must they remain outside of v4l-dvb?
There is already a kernel module called dabusb for ages.
Quoted 5 lines
The Wiki sez, ``some developers already have hardware using standards unsupported by multiproto, such as ISDB-T and DMB-T/H.'' And some of us non-developers have such hardware and want to try it with non-Windows for readily-receiveable DAB.
With some simple definitions ? What applications are used ? With regards to ISDB-T, there was an idea to integrate the ARIB extension used in the DVB V4 API, but then it was proven that there wasn't much use for the same due to:
* lack of available hardware (only some mobile devices using 1 seg or likewise were available) Of course, there was the demodulator from Toshiba TCxxxx, the DVB V4 API which it was based on.
* most of the stuff's completely scrambled and the scrambling schemes are not open like DVB stuff.
But still, if there's need to add support for the same into the multiproto tree, it is quite trivial.
Quoted 4 lines
Or is DAB/T-DMB too different from DVB and related technologies, that a separate development path needs to be taken outside linux-dvb, but probably within V4L?
DMB resembles quite a bit of DAB. Well, the tables for DMB-T/H is quite different from standard DVB tables, but still you can use multiproto to handle DMB-T/H, it's quite trivial.
Quoted 8 lines
Regards,
Manu_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 2 lines · Jelle De Loecker
Is there any change in the cultiproto disecq code?
No newer changes on the diseqc part.
Quoted 8 lines
For example
MythTV won't tune to channels on disecq port 2 or higher. (Disecq port 1 always works)However, Kaffeine works. I'm able to watch every BBC channel on Astra 28,2 (which is on my second port)
This made me think it's MythTV.
There was a post on the VDR ML a while back on the same. It was the DiSEqC Command sequence being used. There was a discussion on that very same topic. You can do a quick lookup on the archives for the same.
Regards,
Manu
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 10 lines · Manu Abraham
Quoted 2 lines · Jelle De Loecker
Is there any change in the cultiproto disecq code?
No newer changes on the diseqc part.
Quoted 4 lines
For example
MythTV won't tune to channels on disecq port 2 or higher. (Disecq port 1 always works)
Quoted 9 lines
Quoted 4 lines
However, Kaffeine works. I'm able to watch every BBC channel on Astra 28,2 (which is on my second port)
This made me think it's MythTV.
There was a post on the VDR ML a while back on the same. It was the DiSEqC Command sequence being used. There was a discussion on that very same topic. You can do a quick lookup on the archives for the same.
We can work together if you want on ISDB-T and DMB-TH if you want! Just to clear out those considerations too.
Best regards,
Markus
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 3 lines · Markus Rechberger
We can work together if you want on ISDB-T and DMB-TH if you want! Just to clear out those considerations too.
I don't have any inhibitions in working with anyone. Whatever work i have done is quite open, where quite a lot of people have collaborated on the same, some way or the other.
But, consider this as an advice, whatever work you put your effort in to, if it goes to the mainline kernel eventually, it can benefit a whole community at large.
Regards,
Manu
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Manu and all,
First I would like to present myself (I'm new to this forum)
My name is Uri Shkolnik, and I work as Software Architecture at Siano Mobile Silicon (www.siano-ms.com).
As some people reading this mailing list know, but some don't.... Siano manufactures chipsets that support various of MDTV standards (DVB-H, DVB-T, ISDB-T, CMMB, T-DMB, DAB-IP,... and many more). Many products you see actually uses Siano's chipsets.
As far as I understand from this thread, and from other threads, the LinuxTV/DVB sub-system will not support non-DVB standards in the near future.
This is quite understandable since those standards are quite complicate, and the newer are even more complicated than DVB-C/S/T. It took about 5 years for the DVB sub-system to become mature, so, trying to add all of those standards at once will lead to nowhere good.
I don't know what should be done next, which API (and sub-system) should be added first, second, ... (or not at all?). I have my own views (CMMB getting much more audience than DVB-H and ISDB-T more than the DAB family).
But, I can offer technical assistant. Siano is senior member at most of the MDTV consortiumes (CMMB, DVB and more) and I have access to lot of technical documentation (specifications, guildlines, etc.) which are otherwise quite hard (if not impossible) to be obtained. True that some (not all) of those papers are under classification that does not permit me to share them directly, but always a specific question can be answered.
One point regarding Siano non-DVB offering - With Michael Krufky's help, I'm trying to find a way to add Siano's non-DVB(-T) offering into the kernel's code base (till now we supply a proprietary sources directly to our customers). Of course it will be somewhat specific code by the fact that it'll match Siano's chipset instead of be more generic.
So, I'm done with the introduction..... :-)
Regards,
Uri
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 10 lines · Uri Shkolnik
Manu and all,
First I would like to present myself (I'm new to this forum)
My name is Uri Shkolnik, and I work as Software Architecture at Siano Mobile Silicon (www.siano-ms.com).As some people reading this mailing list know, but some don't.... Siano manufactures chipsets that support various of MDTV standards (DVB-H, DVB-T, ISDB-T, CMMB, T-DMB, DAB-IP,... and many more). Many products you see actually uses Siano's chipsets.
As far as I understand from this thread, and from other threads, the LinuxTV/DVB sub-system will not support non-DVB standards in the near future.
Well, this is not true. What the idea we put forward was thus:
* have an API that is capable of supporting things which are needed in the future as well, not just for now.
* At the point of working on the same, we mostly worked on DSS, DVB-S2, DVB-H, also for some DOCSIS cable modems. Since these were somewhat suppoted on many hardware we had.
* The Linux DVB V4 API supports ISDB-T and is running on some STB's
http://linuxtv.org/cgi-bin/viewcvs.cgi/dvb-kernel-v4/
This is something which has been proven with regards to the ARIB extensions as well, so we can use the interface of the delivery system in the new API. But having no open drivers which were really supported, really was a let down and the scrambling being employed -- was not something that was open, slowed down things quite a lot, as it was yet to be seen whether such supported hardware drivers would really exist under Linux.
* With regards to DMB-T/H or the Chinese T-DMB, there is quite some people interested on the same, This can be added in to the API at any point of time, without sacrificing backward binary compatibility.
* There was even DVB-T2 in the works at that time, but it was argued and proven right that we shouldn't just blindly keep adding things till we really have support on the same.
You can see my post over here:
http://thread.gmane.org/gmane.linux.kernel/729969
Quoted 2 lines
This is quite understandable since those standards are quite complicate, and the newer are even more complicated than DVB-C/S/T. It took about 5 years for the DVB sub-system to become mature, so, trying to add all of those standards at once will lead to nowhere good.
True, one must look first what hardware will the general home user would like to get going under Linux. There are some features professional users also would like to get going.
But adding all the definitions into an API will be just a mess:
for example ATSC over satellite was a standard that was put forward at some point of time and later on the whole standard itself was scrapped in favour of DVB over satellite.
Quoted 4 lines
I don't know what should be done next, which API (and sub-system) should be added first, second, ... (or not at all?). I have my own views (CMMB getting much more audience than DVB-H and ISDB-T more than the DAB family).
But, I can offer technical assistant. Siano is senior member at most of the MDTV consortiumes (CMMB, DVB and more) and I have access to lot of technical documentation (specifications, guildlines, etc.) which are otherwise quite hard (if not impossible) to be obtained. True that some (not all) of those papers are under classification that does not permit me to share them directly, but always a specific question can be answered.
That would be nice. Well, there are quite some vendors who are willing to help as well. Some of us have access to some of the consortiums, AFAICS. If there's supported hardware out there, we can add in support in the API too, for the relevant delivery systems.
The easiest way to do so, will be to start a discussion, on a newer thread as to what you will need in terms of API support in a newer delivery system.
Quoted 2 lines
One point regarding Siano non-DVB offering - With Michael Krufky's help, I'm trying to find a way to add Siano's non-DVB(-T) offering into the kernel's code base (till now we supply a proprietary sources directly to our customers). Of course it will be somewhat specific code by the fact that it'll match Siano's chipset instead of be more generic.
Regards,
Manu
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 1 line · Uri Shkolnik
First I would like to present myself (I'm new to this forum)
A hearty Welcome from my side, and I hope you have a pleasant stay. Please help yourself to the refreshments from the bar, and have a kipper. ;-)
Quoted 4 lines
I don't know what should be done next, which API (and sub-system) should be added first, second, ... (or not at all?). I have my own views (CMMB getting much more audience than DVB-H and ISDB-T more than the DAB family).
Of course, this will depend on your location -- in some parts of Europe, DVB-H is available as an (subscription) option and DAB is widespread from the provider-point-of-view.
It is from my perspective in Europe that I write, where ISDB-T is not used, but DAB hardware is relatively difficult to find. Still, DAB services have been widely available for a longer time than DVB-T has been operating.
Quoted 5 lines
One point regarding Siano non-DVB offering - With Michael Krufky's help, I'm trying to find a way to add Siano's non-DVB(-T) offering into the kernel's code base (till now we supply a proprietary sources directly to our customers).
When you say `customers', do you mean business customers, for example, TerraTec, which has incorporated your device into the Cinergy Piranha, which I have, and for which the TerraTec-supplied 'Doze media player can sort-of successfully play the available DAB stations? Or do you mean, `end-users' (fnarr) such as myself, who want to use this device under Linux, for more than DVB-T?
Here is my biggest question, which probably could be answered if I used a Real Web Browser.
My Internet access is mostly through a SSH connection to a text- only web-browser on a trusted host, usually on a borrowed connection. So I don't have access to Javascript links, or other non-text offerings -- and often I have no access at all, so I've sort of adopted a UUCP-like way of working', for some values of work'.
In Mr. Krufky's work, I've seen reference to Siano-provided drivers as an alternative to those which he's painstakingly adapted and included in the mainstream. Unfortunately for me, the link is to the main webpage, and from there, normal links lead nowhere interesting. There are plenty of Javascript links that I can't follow. So, I haven't found anything which might help me to answer my further questions myself, and for that, I must apologise.
Quoted 3 lines
Of course it will be somewhat specific code
by the fact that it'll match Siano's chipset instead of be more generic.
I don't see this as a real problem, because I don't know how to weave a generic API from the DAB/DAB+ specs that I've read.
I was hoping to find a diagram of the demodulation process for DAB streams, from the OFDM RF carrier (handled by the hardware) to the mp2/AAC+ audio decoding (in Linux, handled by a userspace software player). Unfortunately, I could not find anything...
Had I found something, I would ask you, if it is not obvious from freely-available code to customers, just where in the chain of decoding, your hardware outputs a stream. I mean, if I supply a channel number such as 12C (VHF), would I be seeing the entire multiplex from which I could extract one particular service, or can I expect something more specific?
I suspect that I would likely find that with different devices (of the few that are available), I'd be tapping into the demodulation-demultiplexing chain at different points, therefore needing to be able to tweak the devices differently appropriate to where I tap into the chain.
But then, I really don't know what I'm talking about.
thanks,
barry bouwsma
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 7 lines · barry bouwsma
From: barry bouwsma <[email protected]>
Subject: Re: [linux-dvb] Multiproto API/Driver Update
To: "linux-dvb" <[email protected]>, [email protected]
Date: Thursday, September 11, 2008, 11:51 PM
--- On Mon, 9/8/08, Uri Shkolnik <[email protected]> wrote:
Quoted 9 lines
Quoted 1 line
First I would like to present myself (I'm new to
this forum)
A hearty Welcome from my side, and I hope you have a pleasant
stay. Please help yourself to the refreshments from the bar,
and have a kipper. ;-)
Thanks :-)
Quoted 15 lines
Quoted 2 lines
I don't know what should be done next, which API
(and
Quoted 1 line
sub-system) should be added first, second, ... (or not
at
Quoted 1 line
all?). I have my own views (CMMB getting much more
audience
Quoted 1 line
than DVB-H and ISDB-T more than the DAB family).
Of course, this will depend on your location -- in some parts
of Europe, DVB-H is available as an (subscription) option and
DAB is widespread from the provider-point-of-view.
Quoted 7 lines
It is from my perspective in Europe that I write, where ISDB-T
is not used, but DAB hardware is relatively difficult to find.
Still, DAB services have been widely available for a longer time than DVB-T has been operating.
I'm not so sure. As I see it, if it depends on number of users DVB-H comes last after CMMB and ISDB-T.
Quoted 10 lines
Quoted 2 lines
One point regarding Siano non-DVB offering - With
Michael
Quoted 2 lines
Krufky's help, I'm trying to find a way to add
Siano's non-DVB(-T) offering into the kernel'scode
Quoted 1 line
base (till now we supply a proprietary sources
directly to
Quoted 1 line
our customers).
Quoted 11 lines
When you say `customers', do you mean business customers,
for example, TerraTec, which has incorporated your device into the Cinergy Piranha, which I have, and for which the TerraTec-supplied 'Doze media player can sort-of successfully
play the available DAB stations? Or do you mean, `end-users'
(fnarr) such as myself, who want to use this device under Linux, for more than DVB-T?
Siano does not manufacture devices. So 'business customers' will fit.
I know the TerraTec device you refer to, and theoretically it can be used as DAB radio receiver. The current LinuxTV lacks the code to support it.
Quoted 17 lines
Here is my biggest question, which probably could be answered
if I used a Real Web Browser.My Internet access is mostly through a SSH connection to a text-
only web-browser on a trusted host, usually on a borrowed connection. So I don't have access to Javascript links, or
other non-text offerings -- and often I have no access at all,
so I've sort of adopted a UUCP-like way of `working', for some
values of `work'.
Quoted 15 lines
In Mr. Krufky's work, I've seen reference to Siano-provided
drivers as an alternative to those which he's painstakingly
adapted and included in the mainstream. Unfortunately for me,
the link is to the main webpage, and from there, normal links
lead nowhere interesting. There are plenty of Javascript links
that I can't follow. So, I haven't found anything which might
help me to answer my further questions myself, and for that,
I must apologise.
You can ask any question you like to, I'll gladly help you with anything I can.
Quoted 4 lines
Quoted 4 lines
Of course it will be somewhat specific code
by the fact that it'll match Siano's chipset
Quoted 8 lines
instead
Quoted 1 line
of be more generic.
I don't see this as a real problem, because I don't know
how to weave a generic API from the DAB/DAB+ specs that I've read.
It's quite simple actually.
There is a open source module from Siano that enable DAB @ Linux. The problem is that this module is not a part of DVB and does not communicates with DVB in any way, but it uses its own character devices in order to communicate with user space applications. It may be converted of course to something that uses DVB, and also be more generic.
Quoted 7 lines
I was hoping to find a diagram of the demodulation process for DAB streams, from the OFDM RF carrier (handled by the hardware) to the mp2/AAC+ audio decoding (in Linux, handled by a userspace software player). Unfortunately, I could not
find anything...
I'm not sure I understand you, so -
1) You always get the digital output from the device (in case of DAB it a framed stream). I don't know any hardware that pipe out the raw modem output.
2) If you refer to the frontend parameters (for DAB family), I can supply you with those.
3) FIB parsing (this is part of the control scheme that is used by DAB) - you get a stream of data frames contain it. Siano offers binary library (user space) that parses it and gives simple API to know what are the available services.
Quoted 10 lines
Had I found something, I would ask you, if it is not obvious
from freely-available code to customers, just where in the chain of decoding, your hardware outputs a stream. I mean, if I supply a channel number such as 12C (VHF), would I be seeing the entire multiplex from which I could extract one particular service, or can I expect something more specific?
DAB is not a multiplex...
Quoted 11 lines
I suspect that I would likely find that with different devices (of the few that are available), I'd be tapping into the demodulation-demultiplexing chain at different points, therefore needing to be able to tweak the devices differently appropriate to where I tap into the chain.
Quoted 6 lines
But then, I really don't know what I'm talking
about.thanks,
barry bouwsma
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Le Friday 12 September 2008 00:23:35 Uri Shkolnik, vous avez écrit :
Quoted 1 line
DAB is not a multiplex...
???
Signature · 7 lines
Christophe Thommeret _______________________________________________ linux-dvb mailing list [email protected] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 6 lines · Christophe Thommeret
From: Christophe Thommeret <[email protected]>
Subject: Re: [linux-dvb] Multiproto API/Driver Update
To: [email protected], [email protected]
Date: Friday, September 12, 2008, 2:16 AM
Le Friday 12 September 2008 00:23:35 Uri Shkolnik, vous avez écrit :
Quoted 6 lines
Quoted 1 line
DAB is not a multiplex...
???
Signature · 1 line
Christophe Thommeret
[ Sorry for the late response ]
My mistake... of course it is a multiplex.
My company's inner terminology (since we deal with multiple DTV standards) always refers to DAB multiplex as "ensemble" (in order to differ it from other multiplex types), and I applied it in this ML.... sorry.
Uri
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 4 lines · Uri Shkolnik
Quoted 2 lines
It is from my perspective in Europe that I write,
I'm not so sure. As I see it, if it depends on number of users DVB-H comes last after CMMB and ISDB-T.
Then let them add their support ;-P I just discovered that
I should be within reception range of a (subscription) DVB-H mux, though sticking a directional antenna out the window did not show any signal (but also not on other previously-received frequencies) -- but climbing a nearby hill should net me a useful signal, maybe two.
For DAB, a simple paperclip antenna will get me one ensemble, a second should be receivable as well, and perhaps with a good antenna, some others may appear.
So, I can test real-world broadcasts and get the actual hands- on experience I need to understand and be able to help -- which is more than I can for the other missing standards, as I'm not so good with the theoretical...
Quoted 3 lines
I know the TerraTec device you refer to, and theoretically it can be used as DAB radio receiver. The current LinuxTV lacks the code to support it.
[...]
Quoted 2 lines
There is a open source module from Siano that enable DAB @ Linux.
Is this something I would be able to download? (Feel free to mail me privately if you don't want it available to other developers, though they could certainly fit it into a suitable API much better than I could)
I've searched with g00gle but haven't found any source to download. (And if drivers under Linux for the other modes (T-DMB, DVB-H) are available, they may help me to better understand those modes as well)
Quoted 5 lines
The problem is that this module is not a part of DVB
and does not communicates with DVB in any way, but it uses its own character devices in order to communicate with user space applications. It may be converted of course to something that uses DVB, and also be more generic.
There is another USB DAB device out there (apparently no longer available, and if so, at an `early-adopter' price) with kernel support.
Perhaps there's some shared functionality that can be combined, somehow, and make easier possibly adding support for some of the small handful of other DAB-able devices.
Anyway, if I'm able to start to play with my device and DAB under linux, that should keep me busy and quiet for some time
thanks,
barry bouwsma
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 81 lines · barry bouwsma
From: barry bouwsma <[email protected]>
Subject: Re: [linux-dvb] Multiproto API/Driver Update
To: "linux-dvb" <[email protected]>, [email protected]
Date: Friday, September 12, 2008, 12:17 PM
--- On Thu, 9/11/08, Uri Shkolnik <[email protected]>Quoted 3 lines · wrote:
Quoted 2 lines
It is from my perspective in Europe that I write,
I'm not so sure. As I see it, if it depends on
number
Quoted 1 line
of users DVB-H comes last after CMMB and ISDB-T.
Then let them add their support ;-P I just discovered
that
I should be within reception range of a (subscription) DVB-H
mux, though sticking a directional antenna out the window did
not show any signal (but also not on other previously-received
frequencies) -- but climbing a nearby hill should net me a useful signal, maybe two.For DAB, a simple paperclip antenna will get me one ensemble,
a second should be receivable as well, and perhaps with a good
antenna, some others may appear.So, I can test real-world broadcasts and get the actual hands-
on experience I need to understand and be able to help -- which is more than I can for the other missing standards, as
I'm not so good with the theoretical...Quoted 1 line
I know the TerraTec device you refer to, and
theoretically
Quoted 1 line
it can be used as DAB radio receiver. The current
LinuxTV
Quoted 1 line
lacks the code to support it.
[...]
Quoted 1 line
There is a open source module from Siano that enable
DAB @
Quoted 1 line
Linux.
Is this something I would be able to download? (Feel free to
mail me privately if you don't want it available to other
developers, though they could certainly fit it into a suitable
API much better than I could)I've searched with g00gle but haven't found any source to
download. (And if drivers under Linux for the other modes (T-DMB, DVB-H) are available, they may help me to better understand those modes as well)Quoted 2 lines
The problem is that this module is not a part of DVB
and does not communicates with DVB in any way, but ituses
Quoted 1 line
its own character devices in order to communicate with
user
Quoted 2 lines
space applications. It may be converted of course to something that uses DVB, and also be more generic.
There is another USB DAB device out there (apparently no longer available, and if so, at an `early-adopter' price)
with kernel support.
Perhaps there's some shared functionality that can be combined, somehow, and make easier possibly adding support for some of the small handful of other DAB-able devices.
Quoted 7 lines
Anyway, if I'm able to start to play with my device and DAB
under linux, that should keep me busy and quiet for some timethanks,
barry bouwsma
[ Sorry for the late response ]
Regarding DAB support -
In order to add full support for DAB ( / DAB+ / T-DMB / DAB-IP / any other ensemble based transmission) you need to have an ensemble parser. This is quite a problem since I'm not familiar with any such decent open source parser.
Anyone?
Uri
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Le Thursday 18 September 2008 21:11:02 Uri Shkolnik, vous avez écrit :
Quoted 103 lines
Quoted 92 lines · barry bouwsma
From: barry bouwsma <[email protected]>
Subject: Re: [linux-dvb] Multiproto API/Driver Update
To: "linux-dvb" <[email protected]>, [email protected]
Date: Friday, September 12, 2008, 12:17 PM
--- On Thu, 9/11/08, Uri Shkolnik <[email protected]>Quoted 3 lines · wrote:
Quoted 1 line
It is from my perspective in Europe that I write,
I'm not so sure. As I see it, if it depends on
number
Quoted 1 line
of users DVB-H comes last after CMMB and ISDB-T.
Then let them add their support ;-P I just discovered
that
I should be within reception range of a (subscription) DVB-H
mux, though sticking a directional antenna out the window did
not show any signal (but also not on other previously-received
frequencies) -- but climbing a nearby hill should net me a useful signal, maybe two.For DAB, a simple paperclip antenna will get me one ensemble,
a second should be receivable as well, and perhaps with a good
antenna, some others may appear.So, I can test real-world broadcasts and get the actual hands-
on experience I need to understand and be able to help -- which is more than I can for the other missing standards, as
I'm not so good with the theoretical...Quoted 1 line
I know the TerraTec device you refer to, and
theoretically
Quoted 1 line
it can be used as DAB radio receiver. The current
LinuxTV
Quoted 1 line
lacks the code to support it.
[...]
Quoted 1 line
There is a open source module from Siano that enable
DAB @
Quoted 1 line
Linux.
Is this something I would be able to download? (Feel free to
mail me privately if you don't want it available to other
developers, though they could certainly fit it into a suitable
API much better than I could)I've searched with g00gle but haven't found any source to
download. (And if drivers under Linux for the other modes (T-DMB, DVB-H) are available, they may help me to better understand those modes as well)Quoted 2 lines
The problem is that this module is not a part of DVB
and does not communicates with DVB in any way, but ituses
Quoted 1 line
its own character devices in order to communicate with
user
Quoted 2 lines
space applications. It may be converted of course to something that uses DVB, and also be more generic.
There is another USB DAB device out there (apparently no longer available, and if so, at an `early-adopter' price)
with kernel support.
Perhaps there's some shared functionality that can be combined, somehow, and make easier possibly adding support for some of the small handful of other DAB-able devices.Quoted 7 lines
Anyway, if I'm able to start to play with my device and DAB
under linux, that should keep me busy and quiet for some timethanks,
barry bouwsma[ Sorry for the late response ]
Quoted 8 lines
Regarding DAB support -
In order to add full support for DAB ( / DAB+ / T-DMB / DAB-IP / any other ensemble based transmission) you need to have an ensemble parser. This is quite a problem since I'm not familiar with any such decent open source parser.
Anyone?
It's always possible to write one :)
Signature · 7 lines
Christophe Thommeret _______________________________________________ linux-dvb mailing list [email protected] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 5 lines · Manu Abraham
Quoted 3 lines
Second, how do non-DVB-like technologies like DAB (Eureka-147) fit into the scope of either multiproto or S2API -- or must they remain outside of v4l-dvb?
There is already a kernel module called dabusb for ages.
I just looked at it again, now that I know a bit more about how DAB works, and to confirm the impression I got earlier when I was thinking about seeing if I could make it work with my (then) new DAB-able device.
This seems to be written specifically for one particular product, which I don't have, and I've forgotten what I've read about it. It seems to be mostly loading firmware to the device, and pulling data from it via USB. I don't see any way to tune to a particular frequency, or select a particular service, so that's presumably done elsewhere, perhaps physically on the receiver itself.
The device I have is partly supported by the v4l-dvb `siano' directory, with hints such as
#define MSG_SMS_DAB_CHANNEL 607
I have what looks to be a personal reply from Herr Acher that has helped me understand a bit more about the dabusb code/device, and I need to welcome the honourable Uri Shkolnik and ask questions to learn about the Siano's support of DAB.
Quoted 4 lines
Quoted 2 lines
And some of us non-developers have such hardware and want to try it with non-Windows for readily-receiveable DAB.
With some simple definitions ? What applications are used ?
I imagine I will have to hack something out of gaffer tape and chewing gum if I want to actually do anything...
Now a completely different question -- I was pleased to see that my not-too-old kernel compiled well with your mp_plus source, and I read on the Wiki that certain basic tools still needed to be ported to multiproto.
Something hands-on like this is probably the only way I'm ever going to get a clue about the APIs. And it might even result in something useful in addition. But I don't have any hardware which requires multiproto, if I'd need that for testing or anything.
Would it be worth it for me to attempt such a port, given that, or will I find it unlikely to get anywhere? I'm no developer and no programmer, and barely a hacker...
thanks,
barry bouwsma
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Barry,
My name is Uri Shkolnik and I'm Siano's software architect.
If you would like to add a generic support for DAB, T-DMB, DAB2, DAB-IP, etc. to LinuxTV, it'll be great!
I can assist you with generic information, plus chipset specific information.
If you have a DAB related RF feed, I even can, on certain conditions, to supply you with a hardware (USB or SDIO based), I already did so before with different open source / Linux projects.
I'm not sure that DVB sub-system is the perfect location for DAB related devices, and what about multi-DTV devices? (Siano based chipsets devices support many DTV standards, DVB-x and DAB-y among them), maybe somewhere up the chain (under media/common ? elsewhere? I'm not pretending to be a Linux kernel nor LinuxTV expert).
Anyway, keep in touch, just letting you know that I'm here... (except my vacation between Sep 19th and Oct 20th :-)
Uri
Quoted 85 lines · barry bouwsma
From: barry bouwsma <[email protected]>
Subject: Re: [linux-dvb] Multiproto API/Driver Update
To: "Manu Abraham" <[email protected]>
Cc: [email protected]
Date: Wednesday, September 10, 2008, 3:52 AM --- On Mon, 9/8/08, Manu AbrahamQuoted 1 line · <[email protected]> wrote:
Quoted 1 line
Second, how do non-DVB-like technologies like DAB
(Eureka-147) fit
Quoted 1 line
Quoted 1 line
into the scope of either multiproto or S2API --
or must they
Quoted 3 lines
Quoted 1 line
remain outside of v4l-dvb?
There is already a kernel module called dabusb for
ages.
I just looked at it again, now that I know a bit more about how DAB works, and to confirm the impression I got earlier when I was thinking about seeing if I could make it work with my (then) new DAB-able device.
This seems to be written specifically for one particular product, which I don't have, and I've forgotten what I've
read about it. It seems to be mostly loading firmware to the device, and pulling data from it via USB. I don't see any way to tune to a particular frequency, or select a particular service, so that's presumably done elsewhere,
perhaps physically on the receiver itself.The device I have is partly supported by the v4l-dvb `siano'
directory, with hints such as
#defineMSG_SMS_DAB_CHANNEL607I have what looks to be a personal reply from Herr Acher that has helped me understand a bit more about the dabusb code/device, and I need to welcome the honourable Uri Shkolnik
and ask questions to learn about the Siano's support of DAB.Quoted 1 line
Quoted 1 line
And some of us non-developers have such hardware
and want to try
Quoted 3 lines
Quoted 1 line
it with non-Windows for readily-receiveable DAB.
With some simple definitions ? What applications are
used ?
I imagine I will have to hack something out of gaffer tape and chewing gum if I want to actually do anything...
Now a completely different question -- I was pleased to see that my not-too-old kernel compiled well with your
mp_plussource, and I read on the Wiki that certain basic tools still needed to be ported to multiproto.Something hands-on like this is probably the only way I'm
ever going to get a clue about the APIs. And it might even result in something useful in addition. But I don't have
any hardware which requires multiproto, if I'd need that
for testing or anything.Would it be worth it for me to attempt such a port, given that, or will I find it unlikely to get anywhere? I'm no
developer and no programmer, and barely a hacker...thanks,
barry bouwsma
Quoted 4 lines
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 6 lines · Uri Shkolnik
Barry,
My name is Uri Shkolnik and I'm Siano's software architect.
If you would like to add a generic support for DAB, T-DMB, DAB2, DAB-IP, etc. to LinuxTV, it'll be great!
Quoted 7 lines
I can assist you with generic information, plus chipset specific information.
If you have a DAB related RF feed, I even can, on certain conditions, to supply you with a hardware (USB or SDIO based), I already did so before with different open source / Linux projects.
I'm not sure that DVB sub-system is the perfect location for DAB related devices, and what about multi-DTV devices? (Siano based chipsets devices support many DTV standards, DVB-x and DAB-y among them), maybe somewhere up the chain (under media/common ? elsewhere? I'm not pretending to be a Linux kernel nor LinuxTV expert).
Anyway, keep in touch, just letting you know that I'm here... (except my vacation between Sep 19th and Oct 20th :-)
Uri,
The policy on this mailing list is not to top-post. Email replies should appear below the quoted text -- please keep this in mind for the future.
As far as your previous comments, please get over the DVB nomenclature. LinuxDVB is the _name_ of the Linux kernel subsystem that deals with digital media, as a whole, *not* limited to DVB-T, DVB-S, DVB-C, DVB-T2, DVB-S2, DVB-C2, ATSC, ISDB-T, DVB-H, DMB-TH, DAB, etc etc etc
Your comment stating that, "the LinuxTV/DVB sub-system will not support non-DVB standards in the near future" is entirely invalid. There is no reason why the LinuxDVB API cannot be extended to support, as you call them, "non-DVB" standards.
Now that you, Uri, have joined our community and are offering help with documentation, specifications, etc, this is a great opportunity to help in adding support for these new standards to the Linux Kernel.
Just so that everybody is on the same page here, there are two API proposals on the table. These proposals deal with ways to extend the
LinuxDVB API for future expansion. The issue being discussed is
*not* how to deal with adding support for additional standards -- we already have that covered. Regardless of whether Manu's proposal or Steve's proposal is accepted, support for the same additional standards will be added, while still leaving room for future expansion.
Once the decision is officially made, as per who's API extension proposal is accepted, then I welcome you to start discussing how we can add support for the additional standards into the kernel.
Please don't reply to this message -- we're better off dealing with this topic in a _new_ thread, after the API discussions have completed. To continue on with this here will only distract from the threads original topic.
Thank you for your input.
Regards,
Mike Krufky
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 6 lines · barry bouwsma
Quoted 3 lines
Quoted 2 lines
And some of us non-developers have such hardware and want to try it with non-Windows for readily-receiveable DAB.
With some simple definitions ? What applications are used ?
I imagine I will have to hack something out of gaffer tape and chewing gum if I want to actually do anything...
Use any of the existing applications, "as it is".
Quoted 5 lines
Now a completely different question -- I was pleased to see that my not-too-old kernel compiled well with your
mp_plussource, and I read on the Wiki that certain basic tools still needed to be ported to multiproto.
Please use the multiproto tree rather than the multiproto_plus tree.
Quoted 9 lines
Something hands-on like this is probably the only way I'm ever going to get a clue about the APIs. And it might even result in something useful in addition. But I don't have any hardware which requires multiproto, if I'd need that for testing or anything.
Would it be worth it for me to attempt such a port, given that, or will I find it unlikely to get anywhere? I'm no developer and no programmer, and barely a hacker...
You don't need to make any ports, neither for the drivers nor for the applications ...
Regards,
Manu
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Am Samstag, den 13.09.2008, 01:43 +0400 schrieb Manu Abraham:
Quoted 28 lines
Quoted 6 lines · barry bouwsma
Quoted 3 lines
Quoted 2 lines
And some of us non-developers have such hardware and want to try it with non-Windows for readily-receiveable DAB.
With some simple definitions ? What applications are used ?
I imagine I will have to hack something out of gaffer tape and chewing gum if I want to actually do anything...
Use any of the existing applications, "as it is".
Quoted 5 lines
Now a completely different question -- I was pleased to see that my not-too-old kernel compiled well with your
mp_plussource, and I read on the Wiki that certain basic tools still needed to be ported to multiproto.Please use the multiproto tree rather than the
multiproto_plustree.Quoted 6 lines
Something hands-on like this is probably the only way I'm ever going to get a clue about the APIs. And it might even result in something useful in addition. But I don't have any hardware which requires multiproto, if I'd need that for testing or anything.
Quoted 7 lines
Quoted 3 lines
Would it be worth it for me to attempt such a port, given that, or will I find it unlikely to get anywhere? I'm no developer and no programmer, and barely a hacker...
You don't need to make any ports, neither for the drivers nor for the applications ...
Linus and Greg don't get their jobs done or do it too well.
Either stay more away from subsystems or come closer.
To let it hang around over years for cheap, is a pity.
Hermann
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 9 lines · Manu Abraham
barry bouwsma wrote:
...Quoted 4 lines
Now a completely different question -- I was pleased to see that my not-too-old kernel compiled well with your
mp_plussource, and I read on the Wiki that certain basic tools still needed to be ported to multiproto.Please use the multiproto tree rather than the
multiproto_plustree.
I tried the multiproto version 855d0c878944, but it didn't work on my system. My VDR doesn't recognize my DVB-T card and hangs upon startup. When I try to unload the driver modules, the 'rmmod budget_core' appears to hang. If I kill that, a subsequent 'lsmod' also hangs, so I need to do a reboot - which also hangs, so a hard reset is the last resort.
Then I tried the latest multiproto_plus version adf34f76ab7c, with which VDR's startup sequence results in
Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter0/frontend0 Sep 14 13:06:59 video vdr: [3313] CI adapter on device 0 thread started (pid=3309, tid=3313) Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported Sep 14 13:06:59 video vdr: [3314] section handler thread started (pid=3309, tid=3314) Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter1/frontend0 Sep 14 13:06:59 video vdr: [3316] CI adapter on device 1 thread started (pid=3309, tid=3316) Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported Sep 14 13:06:59 video vdr: [3317] section handler thread started (pid=3309, tid=3317) Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter2/frontend0 Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported Sep 14 13:06:59 video vdr: [3319] section handler thread started (pid=3309, tid=3319) Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter3/frontend0 Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported Sep 14 13:06:59 video vdr: [3321] section handler thread started (pid=3309, tid=3321)
This is the DVBFE_GET_DELSYS call that apparently fails.
Using the multiproto_plus version 88821ce4ed8d (2008-04-13) works fine. So I'm still using that one for now.
Have there been any API changes since multiproto_plus version 88821ce4ed8d that I would need to take into account in VDR?
Klaus
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 34 lines · Klaus Schmidinger
Quoted 8 lines · Manu Abraham
barry bouwsma wrote:
...Quoted 4 lines
Now a completely different question -- I was pleased to see that my not-too-old kernel compiled well with your
mp_plussource, and I read on the Wiki that certain basic tools still needed to be ported to multiproto.Please use the multiproto tree rather than the
multiproto_plustree.I tried the multiproto version
855d0c878944, but it didn't work on my system. My VDR doesn't recognize my DVB-T card and hangs upon startup. When I try to unload the driver modules, the 'rmmodbudget_core' appears to hang. If I kill that, a subsequent 'lsmod' also hangs, so I need to do a reboot - which also hangs, so a hard reset is the last resort.Then I tried the latest
multiproto_plusversionadf34f76ab7c, with which VDR's startup sequence results inSep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter0/frontend0 Sep 14 13:06:59 video vdr: [3313] CI adapter on device 0 thread started (pid=3309, tid=3313) Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported Sep 14 13:06:59 video vdr: [3314] section handler thread started (pid=3309, tid=3314) Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter1/frontend0 Sep 14 13:06:59 video vdr: [3316] CI adapter on device 1 thread started (pid=3309, tid=3316) Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported Sep 14 13:06:59 video vdr: [3317] section handler thread started (pid=3309, tid=3317) Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter2/frontend0 Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported Sep 14 13:06:59 video vdr: [3319] section handler thread started (pid=3309, tid=3319) Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter3/frontend0 Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported Sep 14 13:06:59 video vdr: [3321] section handler thread started (pid=3309, tid=3321)
Quoted 7 lines
This is the
DVBFE_GET_DELSYScall that apparently fails.Using the
multiproto_plusversion88821ce4ed8d(2008-04-13) works fine. So I'm still using that one for now.Have there been any API changes since
multiproto_plusversion88821ce4ed8dthat I would need to take into account in VDR?
There hasn't been any further API changes after that changeset.
The only other change (to dvb-core) is a backward compatibility add on from Anssi Hannula, but that change i haven't ported yet to the multiproto_plus tree.
Maybe something came up, while merging the two trees .. ?
Let me see what i can dig through.
Thanks for looking it up.
Regards,
Manu
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 8 lines · Klaus Schmidinger
Quoted 7 lines · Manu Abraham
barry bouwsma wrote:
...Quoted 4 lines
Now a completely different question -- I was pleased to see that my not-too-old kernel compiled well with your
mp_plussource, and I read on the Wiki that certain basic tools still needed to be ported to multiproto.
Quoted 7 lines
Quoted 1 line
Please use the multiproto tree rather than the
multiproto_plustree.I tried the multiproto version
855d0c878944, but it didn't work on my system. My VDR doesn't recognize my DVB-T card and hangs upon startup. When I try to unload the driver modules, the 'rmmodbudget_core' appears to hang. If I kill that, a subsequent 'lsmod' also hangs, so I need to do a reboot - which also hangs, so a hard reset is the last resort.
Digging more into this...
Quoted 18 lines
Then I tried the latest
multiproto_plusversionadf34f76ab7c, with which VDR's startup sequence results inSep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter0/frontend0 Sep 14 13:06:59 video vdr: [3313] CI adapter on device 0 thread started (pid=3309, tid=3313) Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported Sep 14 13:06:59 video vdr: [3314] section handler thread started (pid=3309, tid=3314) Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter1/frontend0 Sep 14 13:06:59 video vdr: [3316] CI adapter on device 1 thread started (pid=3309, tid=3316) Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported Sep 14 13:06:59 video vdr: [3317] section handler thread started (pid=3309, tid=3317) Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter2/frontend0 Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported Sep 14 13:06:59 video vdr: [3319] section handler thread started (pid=3309, tid=3319) Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter3/frontend0 Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported Sep 14 13:06:59 video vdr: [3321] section handler thread started (pid=3309, tid=3321)
Quoted 1 line
This is the
DVBFE_GET_DELSYScall that apparently fails.
Does this look like a mix up of the headers ? Also i do see a bad merge with the multiproto_plus tree with the v4l-dvb head :-/
So eventually since the IOCTL doesn't exist in the merged multiproto_plus tree, i guess that's why it is failing.
Regards,
Manu
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb