Thread: HQCT software development

Your right, it does work putput. I forgot to write the change to my embedded setup before I rebooted. Thanks again for the hard work!

Originally Posted by Putput

Hi Mischka76,
Look again at the hqctdll_calls.txt file, I added the calls which are related to Radiator, with these calls you can read parameters like volume, treble, bass and more. The names are different but you can use the calls parallel to the others, there is no need to use/install Radiator to use them.

hmmmm.. so all radiator plugin's work with these calls only?
what if i used only these calls from my app.. would that mean that i can use any radiator plugin and call it from my app? thus enabling my app to use any pc-radio that is supported by radiator?

i didnt have time to do anything on my app for last few days

Originally Posted by mischka76

hmmmm.. so all radiator plugin's work with these calls only?
what if i used only these calls from my app.. would that mean that i can use any radiator plugin and call it from my app? thus enabling my app to use any pc-radio that is supported by radiator?

If it works in one direction, it should work the other way around as well. Can't see any reason why not. My advice: give it a try! Just one thing, Radiator installs a driver (I think for port IO under Windows) that is used by a number of plugins, this means that you also need this driver to make some pc-radios work (especially the PCI cards, USB shouldn't be a problem).

Putput

Originally Posted by mischka76

hmmmm.. so all radiator plugin's work with these calls only?
what if i used only these calls from my app.. would that mean that i can use any radiator plugin and call it from my app? thus enabling my app to use any pc-radio that is supported by radiator?

this idea is old....
As Radiator is missing RDS (and more) I created an advanced interface with Radiator in mind.
I created a radiator driver (so it drives Radiator and its radios - without RDS certainly), a HQCT driver
which is stopped (waiting for reply from Datalex) and a radio driver for a TMC/GPS mouse (you don't see a usage for such a thing ? - yes the name of these GPS mice is wrong they should be called RDS/GPS mice).
I wrote a simple (radio)frontend and if I copy the driver in into its directory it is working like a charm.
I splitted RDS interpretation from the radio driver so all radios can use one (powerful) rds interpreter.

Radio Drivers Round Table

@putput; does the hqct dll you made, also implement the radiator procedures for initializing and de-initializing the device? ie hwiniti and hwdeinit?

Originally Posted by FMode

this idea is old.... (..)
I splitted RDS interpretation from the radio driver so all radios can use one (powerful) rds interpreter.

Radio Drivers Round Table

I have read this thread .. Fmode, you are so modest!

splitting off the rds is a nice idea in itself. but .. take the hqct as example: if the plugin already opened the port, how is another driver gonna read the rds data from the device?

i must admit, lack of rds in radiator is a serious problem that i hadnt realised. its a pitty that radiator development kind of stopped.

i like the way that radiator has set a kind of standard for interfacing a radio device. That is something we should adopt for future drivers, so drivers can then be re-used in other frontends.

Originally Posted by mischka76

@putput; does the hqct dll you made, also implement the radiator procedures for initializing and de-initializing the device? ie hwiniti and hwdeinit?

Yes it does, 100% according to Radiator rules, return values included.

Putput

YES! hasta la victoria siempre!!!!

i can now tune to AM as well. Allas, I receive only static but thats not because of my code. it must be antenna or summit.

good to hear about the radiator implementation. i'll look into that later!

the thing is with radiator: it doesnt just lack RDS, it also lacks AM/FM? I'll have to investigate the amount of users of am and/or other tuner-devices before i make more effort on this.

or maybe Fmode comes up with some miraculous solution.

Originally Posted by mischka76

YES! hasta la victoria siempre!!!!

Originally Posted by mischka76

i can now tune to AM as well. Allas, I receive only static but thats not because of my code. it must be antenna or summit.

Probably

Originally Posted by mischka76

good to hear about the radiator implementation. i'll look into that later!

Request from a dutch guy, you know the dutch guys ..

Originally Posted by mischka76

the thing is with radiator: it doesnt just lack RDS, it also lacks AM/FM? I'll have to investigate the amount of users of am and/or other tuner-devices before i make more effort on this.

I know that the people in the US of A appreciate AM reception a lot, has to do with distances I think. I have a very loyal beta tester on the other side of the ocean, he uses AM frequently.

Originally Posted by mischka76

or maybe Fmode comes up with some miraculous solution.

Originally Posted by mischka76

....

or maybe Fmode comes up with some miraculous solution.

I painted the struture here:
Radio Drivers Round Table

The truth is:
There is no RDS interpretation... the RDS raw stream should be directly moved to the Frontend from the driver. I don't know what services are run over RDS in your conuntry/station - so I may forgot interpretation in my RDS interpreter. So if you programm your own frontend and want to show "RDS paging" (example) you can still use my driver(s)+RDS interpreter and got the RDS paging out of the raw RDS stream.

Frontend's handling of RDS:

Code:

    Private Sub mFMRadioHal_RDSRAWMessageavailable(ByRef RDSRAWMessage As FMRadio.FMRadioHAL.stRDSRAWMessage) Handles mFMRadioHal.RDSRAWMessageavailable
        mRDSInterpreter.decode(RDSRAWMessage)
        string=mRDSInterpreter.CurrentProgram.RadioText
    End Sub

(the RDS interpreter uses an objectual view of RDS - very powerful idea by Aeroanderz)

BTW: blocking/filtering information in a lower layer is always bad...

I would like to have more discussion ! I would like to have more discussion about interface spec's - I am sure there are some things stupid/missing/error.
If you have any concerns that this will not work with a Silabs/ADS Radio.... just ask...


Missing is "audio-mixer-stuff" - these are radiodrivers not "audio". The HQCT is radio with a mixer section.

Interface-Proposal for (radio-)audio-layers:

Code:

Namespace AudioHAL
    'this is the root class !
    Public Interface I_AudioHAL
        ReadOnly Property AudioSources() As AudioSourceCollection ' these Equlizers are at the Input of each Audiosource(Channel)
        '...more to add ?
        ReadOnly Property CommonEqualizer() As EqualizerBand ' this Eqaulizer is at the OUTPUT of our Mixer
    End Interface
    Public Interface I_AudioSource
        ReadOnly Property Name() As String
        ReadOnly Property AudioType() As enAudioSourceTyp
        ReadOnly Property RoutingType() As enRouteType
        Sub Enable()
        ReadOnly Property Equalizer() As EqualizerBandCollection
        Property Volume() As Integer
    End Interface
    Public Interface I_EqualizerBand
        ReadOnly Property Name() As String ' examples "100Hz", "1000Hz", "TREBLE", "BASS", "LOUD", ....
        ReadOnly Property SortID() As Integer 'helps the Frontends to display the Slider for every EqBand in the right order "100Hz" will be 0 "1000Hz" will be 1 - "BASS" will be 0 "TREBLE" will be 1 
        Property Value() As Integer ' 50% or something will be the center - this is the value to control this EqBand
    End Interface
    Public Enum enRouteType
        MIXABLE_WITH_OTHER_SOURCES
        ONLY_THIS_CAN_BE_ENABLED_AT_ONE_TIME
    End Enum
    Public Enum enAudioSourceTyp
        CD
        NAVI
        Radio_FM
        Radio_AM
        Radio_MW
        Radio_LW
        Radio_SW
        CASSETTE
        TEL
        PC_COMMON
        PC_MP3
        PC_DVD
        PC_NAVI
        OTHER
    End Enum

End Namespace

This Audio-DLL (the HQCT version of it) will/should communicate with the FMRadioHAL driver (over WindowsMessages)...