klaji/pulsar

Fork 0

Implement enough of libpulse API to support GrooveBasin #1

New issue

Open

opened 2025-02-25 20:02:19 +00:00 by desttinghim · 5 comments

desttinghim commented

2025-02-25 20:02:19 +00:00

(Migrated from codeberg.org)

@andrewrk wanted to know if Pulsar could replace libpulse in this GrooveBasin code. The answer right now is no, but I would like to change that to a yes! This issue is for tracking which features are missing.

Context state change callback
Background/threaded event loop
Stream seeking
~~Waiting~~ The wait function has not been implemented, but emulating that behavior should be easy since Pulsar allows more control over the event loop than libpulse
Sample rate and sample format selection (at least 48000hz and f32)

@andrewrk wanted to know if Pulsar could replace libpulse [in this GrooveBasin code]([url](https://codeberg.org/andrewrk/groovebasin/src/commit/832f8ec6595e23d70ab63526a406838c05e92ac4/player/root.zig#L585-L763)). The answer right now is no, but I would like to change that to a yes! This issue is for tracking which features are missing. - [x] Context state change callback - [x] Background/threaded event loop - [x] Stream seeking - [ ] ~Waiting~ The wait function has not been implemented, but emulating that behavior should be easy since Pulsar allows more control over the event loop than libpulse - [x] Sample rate and sample format selection (at least 48000hz and f32)

andrewrk commented

2025-02-25 21:08:53 +00:00

(Migrated from codeberg.org)

Subscribed!

desttinghim commented

2025-03-04 07:03:35 +00:00

(Migrated from codeberg.org)

Commit 548f771dff adds support for seeking to Pulsar, complete with an example. The other features have already been implemented. There is still more work to do, but I think the API is complete enough for Pulsar to be used as is. I'll leave this issue until that's been confirmed though.

Commit `548f771dff` adds support for seeking to Pulsar, complete with an example. The other features have already been implemented. There is still more work to do, but I think the API is complete enough for Pulsar to be used as is. I'll leave this issue until that's been confirmed though.

andrewrk commented

2025-03-05 01:01:35 +00:00

(Migrated from codeberg.org)

Looking forward to trying it out!

andrewrk commented

2025-03-10 05:17:24 +00:00

(Migrated from codeberg.org)

You may be wondering why I have not reported back yet.

I noticed that this package depends on libxev. In fact, it depends on a fork of libxev.

libxev is very cool, but deciding to make my project event-based should be an entirely separate question than deciding to use pulsar... or should it be?

This caused me to spiral down a yak fever dream, and long story short I've wild ideas about bringing back async, making all I/O a parameter, and more.

In other words... I won't be able to report back anytime soon. But this will have big consequences on Zig as a language and toolchain.

You may be wondering why I have not reported back yet. I noticed that this package depends on libxev. In fact, it depends on a fork of libxev. libxev is very cool, but deciding to make my project event-based should be an entirely separate question than deciding to use pulsar... or should it be? This caused me to spiral down a yak fever dream, and long story short I've wild ideas about bringing back async, making all I/O a parameter, and more. In other words... I won't be able to report back anytime soon. But this will have big consequences on Zig as a language and toolchain.

desttinghim commented

2025-03-10 07:29:32 +00:00

(Migrated from codeberg.org)

@andrewrk wrote in https://codeberg.org/desttinghim/pulsar/issues/1#issuecomment-2993901:

You may be wondering why I have not reported back yet.

I noticed that this package depends on libxev. In fact, it depends on a fork of libxev.

libxev is very cool, but deciding to make my project event-based should be an entirely separate question than deciding to use pulsar... or should it be?

This caused me to spiral down a yak fever dream, and long story short I've wild ideas about bringing back async, making all I/O a parameter, and more.

In other words... I won't be able to report back anytime soon. But this will have big consequences on Zig as a language and toolchain.

Oh dear... as exciting as the async and IO stuff would be, pulsar does not actually depend on libxev! It is in the build.zig.zon so I can use it for examples/xev.zig. I have just been told that I can add a lazy field to dependencies in build.zig.zon to tell zig not to fetch it if it is not needed. I am sorry for the unnecessary trouble! 😅

@andrewrk wrote in https://codeberg.org/desttinghim/pulsar/issues/1#issuecomment-2993901: > You may be wondering why I have not reported back yet. > > I noticed that this package depends on libxev. In fact, it depends on a fork of libxev. > > libxev is very cool, but deciding to make my project event-based should be an entirely separate question than deciding to use pulsar... or should it be? > > This caused me to spiral down a yak fever dream, and long story short I've wild ideas about bringing back async, making all I/O a parameter, and more. > > In other words... I won't be able to report back anytime soon. But this will have big consequences on Zig as a language and toolchain. Oh dear... as exciting as the async and IO stuff would be, pulsar does not actually depend on libxev! It is in the build.zig.zon so I can use it for `examples/xev.zig`. I have just been told that I can add a `lazy` field to dependencies in `build.zig.zon` to tell zig not to fetch it if it is not needed. I am sorry for the unnecessary trouble! 😅

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

klaji/pulsar#1

No description provided.

Rows
Columns