Further ideas and development

[ann0see]

@gene96817

I saw that you follow me and watch this repo. Furthermore you also created a repo which has a similar idea. Do you want to contribute/have ideas? I'd be happy to have someone else in my team ;-).

[gene96817]

@ann0see I am new to Github. I am having trouble learning more about how you define the problem and your approach to solving it. It does look like we are both trying to solve the same (or similar) problem. Collaborating would be great, but I don't know if we have a compatible understanding of the problem. How many people on your team?

Your approach appears complicated. I can't read between the lines to understand your design. Do you have an architecture design document that lays out your problem analysis and solution? From reading the one doc I found here, some parts seem challenging to implement.

I am in the process of building a proof-of-concept. Without a working POC, I am reluctant to say if I have a better idea. I do have a much simpler solution. Maybe that means my understanding is naive.

Perhaps we should have a real-time discussion and compare our different perspectives and analysis. If you are interested, send me an email.

[ann0see]

I am having trouble learning more about how you define the problem and your approach to solving it. It does look like we are both trying to solve the same (or similar) problem. Collaborating would be great, but I don't know if we have a compatible understanding of the problem. How many people on your team?

Sorry for the mess ;-).

I don't have graphics anymore, but I try to describe it briefly:

Main issue: Musicians, especially students can't reherse online with user-friendly software Solution 1: Use Jamulus.

To do so, they must install it on a PC. There are multiple problems:

• Not every student has a computer; a large number of students does have a smartphone. The school can lend laptops with Windows 10 but probably doesn't have enough of them
• Not many people use LAN nowadays or have an audio interface
• Computer skills of some students and parents are very low. This doesn't mean they can't handle smartphones

Possible quick and dirty solution: Make a big video conference and show them how to set it up. Problem with that: if a student doesn't have a pc/internet connection how should he join? Audio setup with ASIO4All is way too complicated to set it up for everyone. But that's needed.

My idea: Provide dedicated jamulus hardware (Raspberry PI). This also has the big advantage that (at least in headless mode). The students can't easily modify it and it works plug and play.

Description:

Client: Every student has a Jamulus client which is - at least for updates - centrally managed by the school. Jamulus automatically starts and connects to the jamulus server since everything has already been setup (including the audio setup since every client has e.g. a UM2 Interface + microphone connected) --> very easy for students. They only need to plugin the hardware and LAN-cable Administration: e.g. via Reverse SSH (privacy issues but fast fix if something goes wrong and the admin has to fix a client) or unattended upgrades (no way for the admin to really access the clients).

Server: Every client connects to a admin server and a jamulus server. The IPs are set while installing the OS on the clients. If there's an update: either the admin pushes updates or the clients search for updates.

Current status:

The client side works but I moved away from the headless idea since you can't control jamulus properly without GUI (yet).

[gene96817]

Ann0see, I am reading your emails in order. By now you will have seen my earlier emails and starting to understand my perspective. I add some comments below and inline with your email.

Gene

Eugene Chang gene96817@gmail.com eugene.chang@alum.mit.edu 781-799-0233

---

What is the attached file signature.asc? If you use PGP compatible mail software, this file holds a cryptographic digital signature to prove the email was really sent by me. As a bonus, if you are using PGP, our email could be cryptographically secure and private from anyone intercepting the email.

On Oct 12, 2020, at 1:33 AM, ann0see notifications@github.com wrote:

I am having trouble learning more about how you define the problem and your approach to solving it. It does look like we are both trying to solve the same (or similar) problem. Collaborating would be great, but I don't know if we have a compatible understanding of the problem. How many people on your team?

Sorry for the mess ;-).

I don't have graphics anymore, but I try to describe it briefly:

Main issue: Musicians, especially students can't reherse online with user-friendly software Solution 1: Use Jamulus.

To do so, they must install it on a PC. There are multiple problems:

Not every student has a computer; a large number of students does have a smartphone. The school can lend laptops with Windows 10 but probably doesn't have enough of them Not many people use LAN nowadays or have an audio interface Computer skills of some students and parents are very low. This doesn't mean they can't handle smartphones Possible quick and dirty solution: Make a big video conference and show them how to set it up. Problem with that: if a student doesn't have a pc/internet connection how should he join? Audio setup with ASIO4All is way too complicated to set it up for everyone. But that's needed.

I agree the AISO4ALL is a big support problem. Most Windows users don’t understand the concept of drivers.

I don’t think the videoconferencing session will be easy to manage. I think a Windows remote support tool would be better. I wonder if there is an open-sourced remote-support/remote-control tool.

My idea: Provide dedicated jamulus hardware (Raspberry PI). This also has the big advantage that (at least in headless mode). The students can't easily modify it and it works plug and play.

I wonder if booting JamulusOS from a USB stick would be easier to support. I haven’t had time to look at the audio driver issues with JamulusOS. It would be awesome if JamulusOS on an Intel/AMD platform would be as simple to configure as MacOS. That would be a big start.

Description:

Client: Every student has a Jamulus client which is - at least for updates - centrally managed by the school. Jamulus automatically starts and connects to the jamulus server since everything has already been setup (including the audio setup since every client has e.g. a UM2 Interface + microphone connected) --> very easy for students. They only need to plugin the hardware and LAN-cable Administration: e.g. via Reverse SSH (privacy issues but fast fix if something goes wrong and the admin has to fix a client) or unattended upgrades (no way for the admin to really access the clients).

I have worked in this environment/problem space for years. The router world has solved this problem. I can help you define the workflow. A first draft is already in the repository. We could borrow a lot of the management modules from one of the open sourced router projects. Most of them run on Linux.

Server: Every client connects to a admin server and a jamulus server. The IPs are set while installing the OS on the clients. If there's an update: either the admin pushes updates or the clients search for updates.

Yes. In the router world, the routers leave the factory with a GUID and the IP address of the admin server. Then the router is connected to the internet, it connects to the admin server and everything is then managed by the admin server. The admin server will have the data to bind users to their device. The GUID is protected by a cert so there is no confusion about hardware.

For this to really work, the boot process has to be secure to ensure there is no rogue code inserted into the startup process.

Current status:

The client side works but I moved away from the headless idea since you can't control jamulus properly without GUI (yet).

Agreed. And I believe you want to support the video channel between musicians. I don’t know if it makes sense to use the smartphone to control the client device. If you use the smartphone, once you have a bluetooth pairing, the smartphone could serve as mouse and keyboard.

I would not use the smartphone for the video because the mobile networks have very big delays. Maybe you can believe their marketing that their 5G is fantastically fast. Personally, I would not believe any magical claims on the 5G network (for a long time).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ann0see/rasjam/issues/2#issuecomment-707064600, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARAO53OXI755YQKDA32D2UDSKLSQ7ANCNFSM4SMBJGIA.

[ann0see]

It would be awesome if JamulusOS on an Intel/AMD platform would be as simple to configure as MacOS

I set it up once with my integrated sound card and it worked quite ok. But booting a different OS might be tricky too (since every pc handles it differently.)

I have worked in this environment/problem space for years. The router world has solved this problem. I can help you define the workflow. A first draft is already in the repository. We could borrow a lot of the management modules from one of the open sourced router projects. Most of them run on Linux.

Yeah, probably reusing code is the best approach. Nevertheless, I'd wait what the final solution is.

The GUID is basically the hostname in my scripts but there's no security yet. Checking the boot process is not a simple task. The question is if that's really necessary.

I don’t know if it makes sense to use the smartphone to control the client device. If you use the smartphone, once you have a bluetooth pairing, the smartphone could serve as mouse and keyboard.

I'd probably do it over wifi and serve a website via a webserver which controls jamulus. But the headless idea still has many problems. Therefore I'd use a touchscreen for the raspberry pi.

I would not use the smartphone for the video

4G does handle video but the latency is probably bad. Wifi can sometimes handle it.

I also tried Jamulus + Jitsi Meet via the same device (not a Raspi) and the video latency was too big. Jamulus did work well.

[gene96817]

GUID = globally unique ID… it needs a form of serial number spot that each device is unique. If you want security, then this needs to be a cert. If you don’t use a GUID, then you cannot know which device should be configured for user A or user B. You also don’t want a rogue user to change the device name to impersonate another user.

Using wi-fi is a problem if the user wants to set up their device in a place where they do not have control of the wifi network. Bluetooth pairing is easier and the RPi has bluetooth support

Thanks for the comment about Jitsi Meet being slow. I will have to benchmark that. Maybe it is slow because of the browser environment. Do you know of any other open source (non-browser) alternative?

---

Eugene Chang gene96817@gmail.com eugene.chang@alum.mit.edu 781-799-0233

---

What is the attached file signature.asc? If you use PGP compatible mail software, this file holds a cryptographic digital signature to prove the email was really sent by me. As a bonus, if you are using PGP, our email could be cryptographically secure and private from anyone intercepting the email.

On Oct 12, 2020, at 9:41 AM, ann0see notifications@github.com wrote:

It would be awesome if JamulusOS on an Intel/AMD platform would be as simple to configure as MacOS

I set it up once with my integrated sound card and it worked quite ok. But booting a different OS might be tricky too (since every pc handles it differently.)

I have worked in this environment/problem space for years. The router world has solved this problem. I can help you define the workflow. A first draft is already in the repository. We could borrow a lot of the management modules from one of the open sourced router projects. Most of them run on Linux.

Yeah, probably reusing code is the best approach. Nevertheless, I'd wait what the final solution is.

The GUID is basically the hostname in my scripts but there's no security yet. Checking the boot process is not a simple task. The question is if that's really necessary.

I don’t know if it makes sense to use the smartphone to control the client device. If you use the smartphone, once you have a bluetooth pairing, the smartphone could serve as mouse and keyboard.

I'd probably do it over wifi and serve a website via a webserver which controls jamulus. But the headless idea still has many problems. Therefore I'd use a touchscreen for the raspberry pi.

I would not use the smartphone for the video

4G does handle video but the latency is probably bad. Wifi can sometimes handle it.

I also tried Jamulus + Jitsi Meet via the same device (not a Raspi) and the video latency was too big. Jamulus did work well.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ann0see/rasjam/issues/2#issuecomment-707310125, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARAO53IYRA6IHVUMGKGUBOLSKNLYPANCNFSM4SMBJGIA.

[ann0see]

Jitsi actually was the best video conferencing tool but was still too slow. There's also BigBlueButton (the quality is worse with this)