Skip to content

Conversation

@abrasive
Copy link

So... I think this is somewhere between 5 and 10 years too late. But here it is anyway.

This is a port in progress to Symbian S60-based devices; specifically S60v3 (not to be confused with Symbian^3). I doubt you'll ever want to merge it, but it's here as a pointer for any crazy person who might actually want to use it. (I personally just went back to a Nokia E63 after a succession of Android phones, but I don't think that's a popular choice.) With the appropriate SDK and tools it should work on any S60v3 and maybe even v5 device.

The GUI, input and sound all work at this point. Playing sound makes input unresponsive - I think the player thread ends up spinning where it should be yielding.

Anyway, thanks for building such a neat tool, and thank you also for open sourcing it! It's a pleasure to work with such a tidy codebase. I have to say, when I saw you play in Melbourne some five years ago I never thought I'd be pigging out on the phone that was in my pocket that day...

abrasive and others added 11 commits August 19, 2015 12:04
GUI, keyboard, sound all work; keyboard is almost completely unresponsive
when sound is playing though.
- use dirent.h instead of sys/dir.h
- use anonymous, unshared semaphores
	If I understand the code right, these should be independent
	both between UnixSysSemaphore instances and between processes.
	Anyway, named semaphores aren't present on S60.
Presumably not initialised on the platform. Need to fix.
Otherwise makesis bombs with a verification error.
Somewhat more consistent with the S60 standard. Note that the .pkg file at
this point expects to find the `lgpt10k` demo song directory in 'projects'
at build time (this is very useful for testing).
Currently:
a) crashes on exit, and
b) doesn't appear to improve audio latency - still around 300ms on my test
phone.

Does not suffer from the UI trouble that the SDL one does.
@Mdashdotdashn
Copy link
Owner

Hey man.
I'm on paternity leave so I don't really have any time to review stuff but
I didn't want to stay silent to a nice effort. So big up !
Glad you dig the pig

Cheers
/M

2015-08-19 5:11 GMT+02:00 James Laird-Wah notifications@github.com:

So... I think this is somewhere between 5 and 10 years too late. But here
it is anyway.

This is a port in progress to Symbian S60-based devices; specifically
S60v3 (not to be confused with Symbian^3). I doubt you'll ever want to
merge it, but it's here as a pointer for any crazy person who might
actually want to use it. (I personally just went back to a Nokia E63 after
a succession of Android phones, but I don't think that's a popular choice.)
With the appropriate SDK and tools it should work on any S60v3 and maybe
even v5 device.

The GUI, input and sound all work at this point. Playing sound makes input
unresponsive - I think the player thread ends up spinning where it should
be yielding.

Anyway, thanks for building such a neat tool, and thank you also for open
sourcing it! It's a pleasure to work with such a tidy codebase. I have to
say, when I saw you play in Melbourne some six or seven years ago I never

thought I'd be pigging out on the phone that was in my pocket that day...

You can view, comment on, or merge this pull request online at:

#2
Commit Summary

  • S60v3: initial commit
  • Unix adapter compatibility fixes
  • NOTFORMERGE - S60 hack: avoid mixer mutex crash
  • lgpt.pkg: fix UID
  • Ensure CRLF line endings used on lgpt.pkg
  • Move root & bin dir to c:/data/lgpt
  • S60: remove unneeded capabilities.
  • S60: add some notes on the port

File Changes

Patch Links:


Reply to this email directly or view it on GitHub
#2.

http://marc-nostromo.com

@abrasive
Copy link
Author

Wow, congratulations! All the best then (:

  • J

Still has some bleed around the edge but at least it's not horrible.
Depending on the driver, there is little or no control about the output
buffer size. This adds up to several hundred milliseconds on my test phone
(Nokia E63).

This patch adds a delay before submitting samples for playing. If the
system's output counter is too far behind the submitted samples, it waits
until it isn't. This allows some measure of control over the invisible
buffers.

Of course, this introduces a magic value for the lag tolerance. Setting it
too low causes glitches. These tend to be evenly periodic - so maybe
rejigging things to submit (say) precisely 256 samples a throw would allow
pushing this further.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants