How do launch Remote Desktop Connection application on WinCE bootup?

Hi,

How do I auto launch Remote Desktop application (cetsc.exe) on WinCE
bootup?

I have added the following registry entry in platform.reg

[HKEY_LOCAL_MACHINE\init]
"Launch80"="cetsc.exe"
"Depend80"=hex:14,00, 1e,00, 32,00

I get error message as parameter error. I see message "cetsc.exe
started. Cmdline : '80' "
It seems like from "LaunchXX" it takes XX as the command line argument.

Any body can tell me what is going wrong?

Thanks,
Raghav

Bruce
Wed Jun 14 15:01:20 CDT 2006

That is right, to get around this, write a little app that starts from the
Init key and starts cetsc, and then calls SignalStarted() using the
information passed in on the command line (as documented in help)

--
Bruce Eitman (eMVP)
Senior Engineer
beitman AT applieddata DOT net

Applied Data Systems
www.applieddata.net
An ISO 9001:2000 Registered Company
Microsoft WEP Gold-level Member

"Raghav" <raghavendra.kalluraya@gmail.com> wrote in message
news:1150312413.548774.238190@f6g2000cwb.googlegroups.com...
> Hi,
>
> How do I auto launch Remote Desktop application (cetsc.exe) on WinCE
> bootup?
>
> I have added the following registry entry in platform.reg
>
> [HKEY_LOCAL_MACHINE\init]
> "Launch80"="cetsc.exe"
> "Depend80"=hex:14,00, 1e,00, 32,00
>
> I get error message as parameter error. I see message "cetsc.exe
> started. Cmdline : '80' "
> It seems like from "LaunchXX" it takes XX as the command line argument.
>
> Any body can tell me what is going wrong?
>
> Thanks,
> Raghav
>

SergeiR
Fri Jun 16 14:44:23 CDT 2006

Further, as far as I recall, cetsc.exe must get certain [command line]
arguments to actually run something, like a particular format file such as
an .rdp file or a named connection stored in registry.

SergeiR

"Bruce Eitman (eMVP)" <beitman.nospam@applieddata.net.nospam> wrote in
message news:ePsEb2%23jGHA.4828@TK2MSFTNGP04.phx.gbl...
> That is right, to get around this, write a little app that starts from the
> Init key and starts cetsc, and then calls SignalStarted() using the
> information passed in on the command line (as documented in help)
>
> --
> Bruce Eitman (eMVP)
> Senior Engineer
> beitman AT applieddata DOT net
>
> Applied Data Systems
> www.applieddata.net
> An ISO 9001:2000 Registered Company
> Microsoft WEP Gold-level Member
>
> "Raghav" <raghavendra.kalluraya@gmail.com> wrote in message
> news:1150312413.548774.238190@f6g2000cwb.googlegroups.com...
>> Hi,
>>
>> How do I auto launch Remote Desktop application (cetsc.exe) on WinCE
>> bootup?
>>
>> I have added the following registry entry in platform.reg
>>
>> [HKEY_LOCAL_MACHINE\init]
>> "Launch80"="cetsc.exe"
>> "Depend80"=hex:14,00, 1e,00, 32,00
>>
>> I get error message as parameter error. I see message "cetsc.exe
>> started. Cmdline : '80' "
>> It seems like from "LaunchXX" it takes XX as the command line argument.
>>
>> Any body can tell me what is going wrong?
>>
>> Thanks,
>> Raghav
>>
>
>

Raghav
Tue Jun 27 17:05:00 CDT 2006

Hi,

I have one doubt regarding the audio redirection over RDP in WinCE
environment.

I tried playing .mp3 on WinCE locally. It is fine and sampling rate is
44100 samples per second. But if I connect to the RDP server (Windows
XP) and play the same .mp3 file over the RDP server, the sampling rate
drops down to 8000 samples per second. I guess, the RDP server
re-samples the audio stream to 8000 samples per second and sends to the

WinCE.

Canyou please tell me why is it so? Is there any setting that I can do
to resolves this issue.


Thanks and regards,
Raghav

SergeiR
Wed Jun 28 15:42:59 CDT 2006


My guess in this case would be that RDP protocol doesn't allocate a fixed
bandwidth for your audio stream ( unlike iCA, which can set this explicitly)
and so in your specific test case ( i.e. your network bandwidth in general +
network load for that moment + capabilities of your XP machine as as a
server + the complexity of that specific .mp3 file) it became 8 ksamples.
Maybe your RDP connection settings are set to be modem-like rather than
LAN-like ?

You could also experiment with measuring rates for different .mp3 files as
well as try to use real terminal server as opposed to Windows XP to find out
exact cause of this.

On the general note, our company has many customers, who occasionally do
listen to .mps3 files in terminal server mode ( RDP or ICA), but in all
cases it is NOT the intent to match the quality of audio playback of the
same file being played locally. Further in the example I mentioned the
terminal server uses virtual sound card on its side (i.e. terminal server
has no sound card at all, but is capable to play audio in terminal server
mode), which may also be contributing to this.

SergeiR

"Raghav" <raghavendra.kalluraya@gmail.com> wrote in message
news:1151445900.243379.34000@p79g2000cwp.googlegroups.com...
> Hi,
>
> I have one doubt regarding the audio redirection over RDP in WinCE
> environment.
>
> I tried playing .mp3 on WinCE locally. It is fine and sampling rate is
> 44100 samples per second. But if I connect to the RDP server (Windows
> XP) and play the same .mp3 file over the RDP server, the sampling rate
> drops down to 8000 samples per second. I guess, the RDP server
> re-samples the audio stream to 8000 samples per second and sends to the
>
> WinCE.
>
> Canyou please tell me why is it so? Is there any setting that I can do
> to resolves this issue.
>
>
> Thanks and regards,
> Raghav
>

Raghav
Thu Jun 29 12:41:38 CDT 2006

Thanks for the information. One of my observations is like, if I do RDP
to my Windows XP machine through any other XP machine, the .mp3 is
played with 44.1KHz. But if I do RDP from my WinCE machine, same .mp3
is played with 8KHz. Also I tried Point to Point connection, still the
result is same and I don't see much network traffic also. Please let me
know if you have any suggestion on this.

I suspect on RDP it doesn't request for device capabilitis from the wav
driver. In my wav driver I support till 48KHz sampling rate. I feel, it
straigt away opens the driver with 8KHz. which is also supported by wav
Driver. But I am not sure that which factore makes RDP to use this
sampling rate.

Thanks,
Raghav



SergeiR wrote:
> My guess in this case would be that RDP protocol doesn't allocate a fixed
> bandwidth for your audio stream ( unlike iCA, which can set this explicitly)
> and so in your specific test case ( i.e. your network bandwidth in general +
> network load for that moment + capabilities of your XP machine as as a
> server + the complexity of that specific .mp3 file) it became 8 ksamples.
> Maybe your RDP connection settings are set to be modem-like rather than
> LAN-like ?
>
> You could also experiment with measuring rates for different .mp3 files as
> well as try to use real terminal server as opposed to Windows XP to find out
> exact cause of this.
>
> On the general note, our company has many customers, who occasionally do
> listen to .mps3 files in terminal server mode ( RDP or ICA), but in all
> cases it is NOT the intent to match the quality of audio playback of the
> same file being played locally. Further in the example I mentioned the
> terminal server uses virtual sound card on its side (i.e. terminal server
> has no sound card at all, but is capable to play audio in terminal server
> mode), which may also be contributing to this.
>
> SergeiR

SergeiR
Fri Jun 30 11:02:37 CDT 2006

Hi,

It is quite expected, that a fat terminal server client ( like Windows XP
based) shall behave different, than a similar thin client ( like Windows CE
based). It is also expected, that the same thin client would work a bit
different, when connected to real terminal server, rather than to a limited
capability remote acess computer (like Windows XP).

I am not an expert in using RDP protocol with Windows XP - all our
experience is based on the real use of thin clients with true terminal
servers ( like Microsoft Windows 2000 Advanced server or Windows 2003
Server), where admin has more tools to tune up terminal server computing.
Even more tools and settings in Citrix MetaFrame terminal server, like
separate fully controllable data channel for audio.


SergeiR

"Raghav" <raghavendra.kalluraya@gmail.com> wrote in message
news:1151602898.143811.306140@i40g2000cwc.googlegroups.com...
> Thanks for the information. One of my observations is like, if I do RDP
> to my Windows XP machine through any other XP machine, the .mp3 is
> played with 44.1KHz. But if I do RDP from my WinCE machine, same .mp3
> is played with 8KHz. Also I tried Point to Point connection, still the
> result is same and I don't see much network traffic also. Please let me
> know if you have any suggestion on this.
>
> I suspect on RDP it doesn't request for device capabilitis from the wav
> driver. In my wav driver I support till 48KHz sampling rate. I feel, it
> straigt away opens the driver with 8KHz. which is also supported by wav
> Driver. But I am not sure that which factore makes RDP to use this
> sampling rate.
>
> Thanks,
> Raghav
>
>
>
> SergeiR wrote:
>> My guess in this case would be that RDP protocol doesn't allocate a fixed
>> bandwidth for your audio stream ( unlike iCA, which can set this
>> explicitly)
>> and so in your specific test case ( i.e. your network bandwidth in
>> general +
>> network load for that moment + capabilities of your XP machine as as a
>> server + the complexity of that specific .mp3 file) it became 8 ksamples.
>> Maybe your RDP connection settings are set to be modem-like rather than
>> LAN-like ?
>>
>> You could also experiment with measuring rates for different .mp3 files
>> as
>> well as try to use real terminal server as opposed to Windows XP to find
>> out
>> exact cause of this.
>>
>> On the general note, our company has many customers, who occasionally do
>> listen to .mps3 files in terminal server mode ( RDP or ICA), but in all
>> cases it is NOT the intent to match the quality of audio playback of the
>> same file being played locally. Further in the example I mentioned the
>> terminal server uses virtual sound card on its side (i.e. terminal server
>> has no sound card at all, but is capable to play audio in terminal server
>> mode), which may also be contributing to this.
>>
>> SergeiR
>