Posts

Posted on

Working on a cross-platform configuration GUI

Since a few weeks I’ve been thinking about writing a GUI so as to make the configuration of the sixaxis emulator easier.

Mandatory requirements:

  1. run on Linux, Windows, and OS X
  2. allow the configuration of multiple sixaxis controllers (max=7)
  3. multiple configurations for a single sixaxis controller
  4. automatically detect user inputs (keyboard, mouse, joysticks)
  5. save the configurations in a human-readable format

Optional requirements:

  1. detect bt modules and launch the sixaxis emulator (multiple emu + a single emuclient)
  2. detect sixaxis controllers plugged to the usb bus and allow to change bdaddrs of bt modules

For 1. and 5. mandatory requirements, I chose to use wxwidgets/Codeblocks and XML/libxml.

I will try to make a GUI skeleton before the end of this week, and publish some screen-shots on this blog.

Posted on

Back to the latency: my audio system sucks

In my previous post, I warned that I was experiencing some measure inconsistency.

The reason is simple: my audio system sucks 🙁

For some measures, I recorded the LCD audio output, and for some others, I recorded the audio output of my digital audio system.

But my digital audio system is adding an audio latency that varies from about 40ms for PCM 2.0 to about 90ms for Dolby Digital! (the PS3 could introduce some of this latency, see EDIT2)

Speaking of stuffs that may add latency, a good advice I could give is not to use weak usb extension cable.

I changed the following stuffs so as to take better measures:

  • only record the LCD audio output
  • use a better microphone that makes a lot less noise
  • increase the LCD audio output level
  • take all measures within 10cm near the speaker (1m = 3.4ms)
  • only start the sixaxis emulator, and record the sound with another PC

New measures of the response time:

  • Wireless sixaxis: average 112ms, standard deviation 11ms
  • Wired sixaxis: average 108ms, standard deviation 10ms
  • Sixaxis emulator: average 123ms, standard deviation 8ms

Note that this response time probably includes the response time of the LCD audio output, which seems to be quite constant, since the standard deviation is about 10ms in each case.

The sixaxis emulator is adding 11ms latency compared to the wireless sixaxis, and 15ms compared to the wired sixaxis.
This actually shows the sixaxis emulator is doing quite a good job 🙂

EDIT: I took new measures for CSS in Win7 too, it gives a 158ms response time, with a 16ms standard deviation.

EDIT2: I should measure the response time for CSS with my digital audio system, so as to see if the PS3 is a source of audio latency for dolby digital…

EDIT3: all samples in a single archive file

Posted on

Sixaxis emulator: the truth about latency

Warning: I need to work again on these measures. I took some more measures for the wireless sixaxis. These measures are not consistent with my earlier values :s For these new measures, the average game response time with the wireless sixaxis is about 150ms. All values in this post have to be confirmed. EDIT: See my next post.

No suspense: it’s not good.

I measured the average delay between a gunshot action and its corresponding gunshot sound (in BF:BC2).

  • Real wireless sixaxis: 125ms
  • Real wired sixaxis: 139ms
  • Sixaxis emulator: 168ms

Note that this isn’t the controller latency. This is the overall latency for a gunshot.
The difference between two values gives the controller latency difference.

The sixaxis emulator adds a 43ms latency. That’s more than 1 or 2 frames (40ms@25fps, 33ms@30fps, 17ms@60fps). Not good at all.
I should take some measures with a FPS on PC.
125ms seems to be very high for a descent game controller.
The wired sixaxis gives more latency than the wireless one… not as expected.

Methodology:

– plug a microphone on the PC
– start audacity
– start a FPS on the PS3
– put the microphone on the device to test (sixaxis or mouse)
– adjust the volume of the game so that gunshot actions/sounds are recorded
– start recording in audacity
– repeat the gunshot action (empty the cartridge of a pistol) with ~2s delays
– stop recording
– get measures between gunshot actions/sounds and compute the average

I don’t know how precise it is to measure the game latency, but it’s at least good enough to compute a latency difference.

Following images are screen-shot examples of the audio wave:


As you can see in the second screen-shot, there are two events: the gunshot action (mouse clic) and the gunshot sound. It shows a capture recorded with the sixaxis emulator. The delay was about 150ms for this gunshot.

EDIT:

I took measures for Counter Strike Source in Win7. I get a 188ms average response time for a gunshot.

Although all the measured values seem very high, it seems the real sixaxis and the sixaxis emulator are not that bad… compared to CSS results.

Posted on

Multiple sixaxis emulators

It’s working!

As you can see in the following screenshot, I am able to launch two emu processes that communicate with my PS3, each one using a different bluetooth adapter. I then can connect an emuclient process to one of them.


The next task is to connect the same emuclient to both emu processes, so that each emu process can send commands to the PS3 at the same time.

This will need some more work, as the SDL 1.2 library (that is used to get events from input devices) is not supporting multiple mice and multiple keyboards. It supports multiple game devices though (joysticks, wheels, gamepads…).

EDIT:

It’s not working for the following stuff:

– connect to a PS3 that already has a real sixaxis connected
– connect a real sixaxis after a sixaxis emulator and change the controller id

Posted on

How to connect to an already started PS3

I took some time to analyze the hci dumps I got with the sixaxis proxy.

I discovered what was preventing the sixaxis emulator to connect to an already started PS3.

The magic command is:

sudo hciconfig hci0 class 0x508

Explanation:

The following command gives the class of the bluetooth adapter:

hciconfig hci0 class

For ex my broadcom adapter has the following class:

Class: 0x480100
Service Classes: Capturing, Telephony
Device Class: Computer, Uncategorized

After executing the command, it gets the following:

Class: 0x000508
Service Classes: Unspecified
Device Class: Peripheral, Gamepad

That’s the class of a sixaxis, and for a mysterious reason, it seems that the PS3 only checks it if it’s already started!

Tip: execute this command after each hard/soft reset of the dongle.

To come: several sixaxis emulator running at the same time!

EDIT: this already was suggested by Jim Paris on forums.ps2dev.org (seems to be down right now but it’s still available in google cache)

  • set bluetooth dongle in slave mode, piscan, class 0x000508

I don’t know why, but I missed that each time I read this forum thread :\

Posted on

Some new stuff coming soon…

Since the beginning of my work with the sixaxis emulator (once again, based on the great work of Jim Paris), I have been looking for a way to get a dump of the bluetooth packets that are received and sent by a real sixaxis.

In May of this year, I was told by a reader of my blog that another French guy called Mikael Bouillot developed a sixaxis proxy. He is sharing his work on his website. I didn’t get it work after some early tests and didn’t go further until a few days. I asked Mikael some help to get his proxy working on my side, and he gave me the solution on a silver platter!

I’m now able to get the dump of the connection of any sixaxis.

Thanks to the analysis of these dumps, I hope to solve the following issues:

  1. the sixaxis emulator can’t be started if the PS3 is already started
  2. another instance of the emu process doesn’t work (probably the same issue as 1.)
  3. since the 3.50 firmware version, some more requests are sent by the PS3

Stay tuned, some great stuff should come very soon!

Posted on

Ubuntu & PS3 upgrades

I upgraded my PS3 to the 3.50 firmware, and my PC to the 10.10 Ubuntu version.

It works without any trouble on my side.

There’s a new trace in the emu process traces (“Unknown feature report […]”) but it doesn’t seem to cause any issue. It seems the 3.50 firmware sends some more bt requests. Ideally the sixaxis emulator should respond to these new requests. It’s added on my task list.

If you meet problems, please report them.